Solving the system architecture jigsaw

Today, he thinks, an architecture is likely to be developed from a more advanced starting point and to be influenced by a range of factors, even including the product's form factor and packaging. Rule number one? "Understand what the requirements are for the product," he said. "That used to mean what CPU do I use; should it be a 386 or a 486? Now, it's what's the shape, how many buttons does it have, what's the colour? All this is part of the design process, along with knowing how much the product will sell for and how much it must be made for." Understanding the requirements means asking the customer – who could be internal as well as external – what the product needs to do. "That will define the project," Martin claimed. "Does it need to be small? Should the battery life be doubled?" Form factor is increasingly an important factor. "If I'm trying to squeeze a computer into a sugar cube," Martin offered, "my work will be cut out, but it will define the system architecture will look like." Determining the requirements is a matter of conducting a number of negotiations, Martin continued. "It's communication between you and the client." With the requirements understood, it's back to the design process. Now the question is how close to the blank sheet of paper do you start? "Ask the client what technology is available; can it be enhanced? Is there something which can be added that hasn't been thought of which might bring added value? "When designers are busy and trying to get a lot of things done, they can have a narrower vision about what the end product might look like. The process can be considered as 'cooperative innovation', where a number of people add to the innovation and you end up with a better design." Who is the client? If you're working with a tier 1 defence company, you'll have a different way of engaging than with a company that wants to get a product to market quickly. "With the defence company," Martin observed, "you'll be working with the structured V model because there will be a lot of things you need to be careful about. You'll go through requirements analysis and system design, then come out on the other side of the V, where you'll be testing against requirements. "However, in the rapid engineering model, the initial product idea might be fixed and followed by a two week design cycle to get some kind of hardware. You might use a 3D printer and a Raspberry Pi, for example, to see what the product looks like and to get a 'pre prototype' in the hands of the sales and marketing people. Then you can say it's OK and continue or loop back." How do standards fit in? "They are one of the design constraints," Martin accepted. "But standards can be both a constraint and a friend when developing architectures. They are friends in that if you need to make something which communicates with the outside world, you have a range of standards to access – Wi-Fi, Bluetooth and so on. It's the big difference between today and a couple of decades ago." Standards constrain the system architecture when it comes to things like CE marking; complying with the Low Voltage Directive, for example. "IEC26262 – for functional safety in automotive applications – is interesting," Martin noted. "It's asking the designer at all stages whether they have designed the product – or part of the product – to be as safe as possible. But there's quite a bit of interpretation involved." He pointed to the system architecture of a car. "How safe does the in car entertainment system need to be?" he asked. "It's an entertainment system, but the 10in display not only displays the radio channel, but also a map. How safe does that have to be? Designers have to ask these types of questions." Going through this process can consume a lot of energy. "Ask yourself if you are thinking broadly enough. Have you considered everything? What assumptions have you made?" Product life will also inform the system architecture. "What is the design life? At one end of the scale is a nuclear reactor; at the other, there could be something like toothpick. Somewhere in between are hand held devices which could have a 10 year life. "Consider a car. By the time it's designed and in the market, it could be 10 years since the original thoughts. In 10 year's time, there could be autonomous cars; what do I do today to accommodate autonomous systems?" One solution is to adopt, as far as possible, a platform based approach. "If you have a platform with multiple processing modules, make sure they can be upgraded by software," Martin advised. "Plug in modules can be used to upgrade the product and think about designs which have a flexible configuration." Here, he suggests software upgrades as a means of extending a product's life time and applicability. "New features can be released by a software upgrade and that can be planned at the design stage; double the amount of memory, use a bigger processor." What about which functions go into hardware and which go into software? "It depends, the product and form factor can be an influence here. Can I fit all the hardware into the space available? If I can, what are the thermal issues? The hardware architecture influences the electrical architecture and this may impact the software architecture." Whatever approach is taken, security is now something that needs to be considered in all architectures. "Who would have thought that industrial systems would be subjected to attacks?" he asked. "Nobody thought they would be vulnerable. Now, designers have to think about security for today, but also for tomorrow. Once, cyber attacks were rare and, once, nobody outside of a sci-fi novel thought a car might be vulnerable. Assess the threat and how much effort you need to invest in countering threats." What other factors affect the architecture? "Time to market will influence your thinking; you might want to go to market with something which doesn't meet all the requirements but it will be out there and will have an upgrade path." Martin suggested products can be brought to market more quickly by looking to see what's available off the shelf and whether it makes sense to use such components. "Or does the customer want a 'clean sheet' design because of IPR [intellectual property rights] concerns? It all comes down to what makes sense for a particular product, a particular client and a particular market. But the use case comes before everything else," he concluded.