Safety critical architecture deployed in breakthrough liver perfusion system

The system would keep a human liver at body temperature for 24hrs while maintaining a supply of blood to the organ. It had to be battery powered, not too heavy and feature a simple user interface. Above all, it needed to be fail safe. The challenge was to transform a room full of manually controlled equipment into a self governing unit that could be transported in a range of vehicles. So where did Team start? Chris Ferris, head of electronics and software, said there are three elements to consider when you're at the 'blank sheet of paper' stage and looking to develop a system architecture. "Human factors, how the device will be used; product design, what it looks like; and engineering, what's inside the box." Ferris says its good to start with a risk assessment. "IEC60601 is well written for this. But you also need to have a mental checklist and bring experience to bear on critical systems before you start to think about hardware and software." He suggests the first question you should ask is which parts of the system are critical? "What are the bits that just can't go wrong and how can they be restricted or partitioned?" In his view, most of Organox' subsystems were critical. While a complex design, Organox is intended to be simple to use. "The goal was for the operator only to have to press the start button," Ferris said. "Because it's handling a live organ, there are many things to think about and we tried to simplify things." The next stage is asking yourself whether you can afford to do functions in hardware or should you do them in software? "If it's the latter, will it be reliable?," he asked. If you're working on a client driven design, you may have to question assumptions. "It can surprise the client to find its assumptions aren't valid. So you have to ask what the system should do and investigate from first principles how to implement those functions. You will go back further than the client anticipated, but you do so with good reason." Sebastien Cuvelier-Mussalian is an engineering consultant with Team. "Safety critical systems can have hardware and software solutions. The architectural design process is all about finding out which is best. But solutions often form two parts: safety critical; and user aspects. By keeping these two separate, safety critical operation is maintained, while the user interface gives the right 'look and feel'." Ferris said: "We normally look at proofs of principle. If you have decided to implement a function in hardware or software and it hasn't been done before, then it needs to be proved. Some projects may require a number of such proofs and it may be that we need to build rough prototypes. "The balance between hardware and software differs in each project Team handles and where a novel solution has been proposed, we will try to prove it in isolation." However, Cuvelier-Mussalian said there is validity in trying to find commonality between projects. "We can think about designing safety critical architectures in similar ways. Safety critical elements can be assigned to 'bins' and a system designed around them. When all elements are brought together, safety critical and user functionality look as though they are part of one big system, but they are designed to be separate." Ferris picked up the theme, citing Team's master control board (MCB) approach. "It has all the safety critical stuff we might need to use. We can then look at which pieces of the MCB we might apply. But it doesn't always happen that way." Other questions that can be asked include 'what happens if the battery is here?' and 'what's the effect of a display that's half this size?'. How the product will be used also informs the architectural decisions. Ferris noted: "An electronic engineer might group the buttons on a keypad in a particular way, but a human factors designer might do it differently. Many assumptions are based on what people have seen, not what the product should actually look like." Budgetary considerations will also play a role. Cuvelier-Mussalian said: "Don't forget most clients come with a fixed budget and that will sometimes influence the architecture. Sometimes, there's no point in including an embedded GUI, so simplify the system and make it cheaper to manufacture." Once the hardware and software elements have been identified, it's time to move to the design phase. "It's not necessary to use the latest and greatest devices," Ferris asserted. "We have broad knowledge of processors, for example, so we can make sensible decisions. While customers might push for a particular microcontroller, our MCB approach allows us to determine the best solution." The designers will start to think about integration if the product is likely to be high volume. "In this case, the design would end up in an SoC," he admitted, "but our work is well ahead of that point." In fact, Ferris now finds it hard to justify custom designs. "Five years ago, we would have had that in mind; today, there are many microcontrollers that are versatile enough to be used instead." Team designs all products to use a real time operating system, although there is hard coding of some elements. "We wouldn't use Windows to drive a safety critical part of the system," Ferris said, "but it could be used for the user interface." Ferris is also reluctant to include too many functions in software. "It's surprisingly easy to do and understandable. You get to point where you are doing more in software than you want, so there comes a time when you have to say no. Ask yourself whether a software solution will be reliable; it may be preferable to dedicate pieces of hardware to the tasks." Cuvelier-Mussalian added: "Hardware is simple to test – there's an input and an output. Software is always a grey area: can you guarantee it will work? You are never 100% sure, but you try to be as sure as possible." Risk continues to be assessed as the project progresses. "Iteration of the risk management process is important because you're doing a lot of things in parallel," Ferris counselled. "Software standards don't talk about possibility of harm; it's assumed to be completely safe or completely unsafe and if you don't manage risk, you'll create something which isn't safe." Cuvelier-Mussalian summed up the challenge of Organox. "We took a complex problem which hadn't been solved and applied scientific, medical and engineering knowledge to create a simple solution it works from just three buttons. But there's a lot of processing going on behind the scenes." Team consulting was named consultancy of the year at the 2012 British Engineering Excellence Awards for its work in developing the Organox system. For more information on the awards go to www.beeas.co.uk.