Where to start?

Time to market is a precious commodity; so much so that many new products start life based on a reference design. That's an understandable starting point for many companies where not only time, but also expertise in particular technologies, may be at a premium. But once in a while there comes the need for the design process to start with that legendary 'blank sheet of paper'. Faced with the enormity of making the first few pen strokes on that piece of paper, what should the designer be bearing in mind? The engineers employed by Cambridge Consultants have experienced these same emotions many times during the company's 50 year history. So what advice can one of the company's consultants impart? Senior consultant Martin Cooper, pictured, has more than 20 years' experience of embedded systems development. He says the process can be split into two distinct themes: architectural; and check points. "A number of themes run through the architectural design process," he noted, "and some of these themes may also be of use when it comes to project management." One thing which Cooper is keen to point out is that the discipline of system engineering is independent of product. "Each design is different, but you need to adopt a consistent approach." But things which should be at the top of the list include safety and reliability. "When you're looking at an architecture and trying to assess whether it's good enough, you must consider safety and reliability. At the 'blank sheet of paper' stage, thinking about the requirements will guide you towards certain styles. For instance, if safety is important, that will probably steer you towards a system with less software. If safety is critical, then you might be looking at a redundant system, with two or three functional blocks and a voting system." He says that while most systems can be constructed from software, that can be a weakness. "When you have systems with large software content, you need things to guide you; best practice for example." Meanwhile, Cooper pointed out a number of things which designers should consider when developing and evaluating candidate architectures. Point number one within the architectural theme is to define the scope of your system. "It may seem obvious, but you need to decide – and document – what is in the scope of your system and – importantly – what is not," he advised. Having done that, you need to understand how your system interacts with its environment. "This needs to be through intended interfaces," he continued, "as well as through unintended interfaces." How does he define an 'unintended interface'? "It all comes down to requirements. In an ideal world, you understand the requirements perfectly; they are consistent and there are no omissions. So intended interfaces include things like USB and Ethernet ports. Unintended interfaces are an admission that the ability to specify a system is imperfect. For example, heat generated by one board could affect the performance of the next board in a rack. These are things that might be overlooked." If you work in a company where you can access the expertise of fellow or senior engineers, then do so. "Use their experience," Cooper advised. "Learning about their successes and failures when working on previous projects should provide you with some valuable lessons for the future." While it is important to draw on lessons from past projects, don't only look backwards. The reason? Technology moves forward too quickly. "Because technology advances rapidly," said Cooper, "solutions that may have been correct in the past may not be appropriate for designs starting today." Another area of which to be wary is the ever changing specification document. Marketing departments are always eager to add 'just one more thing' to a specification. That's all well and good and some flexibility is needed to make a product more attractive. "But beware of internally generated feature creep," Cooper counselled. "Although it is useful to create an architecture that can accommodate the inevitable specification changes, bear in mind that the flexibility you build in will come at the cost of increased complexity." Don't be fooled into thinking that you can trust your instincts, or gut feel as Cooper terms it. "Use quantitative approaches where appropriate," he advised. Remember that communication is an important part of the process, not only within the design team, but also with an external customer if there is one. "Adopt a consistent notation that helps with communication," he said. And remember to keep records. "Maintain an audit trail of the decision making process. Remember, an audit trail may well be necessary in some regulatory regimes," he continued. However, there is always room for a review process. "Review and update your architecture processes to improve your organisation's performance the next time around," he said, adding: "Recognise that, in all but the strictest waterfall model processes, architecture design is an ongoing process, not an isolated task." Hopefully, you will now be at the point where you have at least two possible architectures from which to choose. So what are the next steps? Cooper said there are a number of points to bear in mind. First, and more than likely obvious, is to check that the architectures you're comparing all meet the requirements. "You can use traceability to demonstrate this point," he suggested. "Similarly, make sure you understand the safety requirements for the project and the level of safety integrity available from your potential architectures." Consider how the various architectures might fail and how reliable each may be. "Use modelling techniques, such as failure mode and effect analysis or fault trees to help in this respect." Remember also that cost is an important element of any design; your initial brief may well have included a target price. So develop a unit cost model, Cooper advised. "Work with your partners – suppliers and manufacturers – to keep the cost model accurate." And, bearing in mind that time is money, try to ascertain whether each of the candidate architectures will meet the development costs and timescales associated with the project. How have the performance targets been laid out in the requirements document? Make sure each candidate architecture is capable of meeting those requirements. Use modelling or simulation techniques to help you determine whether or not they do. One of the performance targets may have been power consumption, so consider this also. How might each candidate architecture affect such things as staff availability? Cooper pondered. "Think about available skill sets and whether the selected architecture might provide opportunities for skills development." If the necessary skills aren't available in house, then work out how to solve this problem. "Where appropriate," he suggested, "take 'make or buy' decisions. Reuse internally developed IP or buy it in from external partners. But, where third party IP is used, make sure that you understand the terms of the license." The product life cycle is becoming a far more important element in design. Do the candidate architectures support servicing, for example? "And have you considered end of life recycling and disposal?" Cooper concluded.