\n| Device is off<\/td>\n | Power button is pressed.<\/td>\n | Display shows home screen.<\/td>\n | 200 ms<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nAlarm concept<\/h5>\nA medical device can often also trigger alarms. These alarms can be visual, audible, or distributed. A distinction is made between technical alarms and physiological alarms. Technical alarms indicate something is wrong with the device. Physiological alarms indicate something is wrong with the patient. These alarms are covered in standard 60601-1-8. In the system architecture, you can define how you want to implement the alarm output and whether you need redundant outputs.<\/p>\n Design and mechanical structure<\/h3>\nA picture is worth a thousand words. This saying holds true here, too. Often, there is a design draft of what the device should look like (or a previous device). It's much easier to understand a system when you see it. If you have design drafts, incorporate them into the system architecture. These images don't need to correspond exactly to the finished device. The system architecture isn't like a drawing or a design specification. It should reflect how the system is structured and what it looks like in principle.<\/p>\n Include information about what it looks like "under the hood" here. It's important to remember that the system architecture is a living document and that you should update it when components or the device's design change.<\/p>\n If your device has complex wiring or piping, this is the right place to show it.<\/p>\n Power supply<\/h3>\nMost systems require power. It doesn't make sense to overload the block diagram with the fact that almost every component in the device requires power. Therefore, it's a good idea to create a separate chapter for this.<\/p>\n In the power supply section, all sources should be specified (e.g., AC power connection, power adapter connection, internal rechargeable batteries or batteries, goldcaps. Don't forget the RTC battery if you have one). The priority of the sources should be defined (the battery is only used when the power adapter is not connected or function xyz is activated). Also define when the battery is charged (e.g., whenever the device is connected to the mains and the battery is < 90% charged).<\/p>\n Next, describe the main consumers (components) and which components are required for switching the power grids. It is not necessary to mention components at the circuit board level. It is important to define how the power supply works in the system and which components are involved. It should also be defined what happens if one of the sources fails (mains failure, battery failure).<\/p>\n Describe how much power the device consumes and what power peaks you expect. Consider the device's runtime when powered by a rechargeable battery or battery. Explain how the device behaves when turned off. Is it truly de-energized, or is a microcontroller running in a power-saving mode somewhere?<\/p>\n You can also outsource this document and reference it.<\/p>\n Description of the software systems<\/h3>\nA device usually contains software. This is contained on one or more controllers. It is useful to demonstrate which controllers exist and what tasks they perform. This does not need to be done with requirements at this point; a prose description is sufficient. Furthermore, the safety classification according to IEC 62304 can be performed here. The safety class of the individual software systems is defined. It is advisable to divide the software tasks so that the safety class is as low as possible for microcontrollers with a large amount of code (usually GUIs with operating systems). The safety classification is determined by risk management.<\/p>\n When describing the software systems, it should also be determined which software already exists or will be purchased (SOUP\/OTS software). At the system level, this does not concern software libraries, but rather software that is completely adopted (e.g., the firmware in a battery that is not developed in-house). The complete list of SOUP and OTS software must be created elsewhere by the software manager.<\/p>\n At this point, the interfaces should also be named and the protocols between the microcontrollers referenced. The hardware interfaces (UART, SPI, CAN, USB, GPIO, etc.) should be defined, as well as the transfer rates and interface-specific parameters (handshake, 8n1, master-slave, etc.). The protocols define which information is transmitted and in which format. Make sure that all protocols are present.<\/p>\n Operating concept<\/h3>\nThe operating concept describes the device's user interface in detail. Especially for projects with a large software component, an operating concept clearly reflects how the product should look. The operating concept is created in close collaboration with the product manager. The operating concept should be maintained in a separate document. PowerPoint, Inkscape, or other drawing programs are good choices here. You should incorporate the key elements from the operating concept into the system architecture. What operating elements are there? What displays are there? How is the operation basically implemented? You can reference the operating concept in the system architecture.<\/p>\n What should be considered when designing a system?<\/h3>\nBuild your systems as simply as possible (KISS = keep it stupid simple). Reduce complexity as much as possible. This requires constantly questioning whether a component is really needed. Figuratively speaking, you need to step back from your drawing board and ask yourself: "Can I simplify something further?" And if the answer is "yes," then keep doing it until you get the answer "no." The effort is worth it, because system complexity leads to excessive testing and unmanageable systems. You can also simplify the system by structuring it better. Assign tasks to the system components and minimize the number of interfaces.<\/p>\n Especially in medical technology, you have to be able to rely on your devices. It doesn't help anyone if the device crashes at the slightest sign of a malfunction and leaves the patient stranded. Therefore, build your systems with fault tolerance in mind. Consider when essential performance characteristics are no longer met, resulting in a device failure. Consider which parts are acceptable for failure and how the other components should react.<\/p>\n Strictly define your system boundaries (what is mine and what isn't?). Fully define the interfaces at the system boundary. Information, energy, or substances can be exchanged via these interfaces. Information comes, for example, from an ECG electrode as voltage or from another device via a USB interface. Energy comes from the outlet or a power supply. Substances could be blood, water, or other substances. Don't forget the mechanical interfaces. For example, a device might have a wall mount or a protective case. Be accurate when describing these interfaces.<\/p>\n Make sure the system is described completely. This is sometimes not so easy, as you have a lot of information in your head. However, this information also belongs in the system architecture. Therefore, question whether the system is described comprehensively without searching for information in your memory. Checking a system for completeness is easiest if the reviewer can read through the system architecture and then explain to the author how the system works. If the reviewer doesn't understand the system and still has questions or can't explain it, then information is missing.<\/p>\n Describe the system completely, but don't go into too much detail. It doesn't matter which voltage regulator the hardware developer wants to use or what the software should look like. That's the domain of the respective experts. You are responsible for describing the system, and you shouldn't unnecessarily restrict the solution space of the domain experts from the hardware, software, and mechanical areas. It's a good idea to review the results of the domain experts to see whether their solutions fit your system.<\/p>\n When designing systems, you should also keep manufacturing costs in mind. It's pointless to design a great system if no one buys it in the end because it's far too expensive. Manufacturing costs are an important aspect that can have a decisive influence on the architecture.<\/p>\n Also make sure the system is manufacturable. This sounds obvious, but it's often overlooked. Discuss your system architecture with manufacturing early on. Initial models (SLS prototypes) can help here.<\/p>\n Consider how the system can be easily tested. It's a good idea to provide interfaces that you need for testing purposes. Ideally, the tests should be automated. Also consider tests that can assist you during development (e.g., an EMC test interface).<\/p>\n Create a safety concept early on. In this document, you document how the system is structured and which safety measures you have defined. The focus here is on safety. For example, you may have dual-channel controls for safety-relevant components. Or you may use redundant hardware to monitor parameters. There may also be mechanical protective measures (pressure relief valve, reverse polarity protection). Here, you also describe the self-tests and device monitoring during runtime and other considerations that contribute to device safety. This document is very useful for discussing the design with the approval authority early in development.<\/p>\n |
![\"systemContext\"](\"https:\/\/www.medtech-ingenieur.de\/wp-content\/uploads\/2015\/03\/systemContext.png\")
<\/a>![\"blockdiagram\"](\"https:\/\/www.medtech-ingenieur.de\/wp-content\/uploads\/2015\/03\/blockdiagram.png\")
<\/a>![\"statemachine\"](\"https:\/\/www.medtech-ingenieur.de\/wp-content\/uploads\/2015\/03\/statemachine.png\")
<\/a>![\"wirkkette\"](\"https:\/\/www.medtech-ingenieur.de\/wp-content\/uploads\/2015\/03\/wirkkette.png\")
<\/a>![\"signalepsel\"](\"https:\/\/www.medtech-ingenieur.de\/wp-content\/uploads\/2015\/03\/signalepsel.png\")
<\/a>