What is a system? What initially sounds like a simple question can sometimes be complex. The question is not easily answered. The answer depends on the perspective and the development context. But why should we even ask the question? Systems today are becoming increasingly complex and interact with other systems. To manage the resulting complexity, the "divide and conquer" approach helps. Systems are thus broken down into subsystems.
A system is thus a recursive structure and consists of systems. This whole structure is often referred to as a "system of systems."
In this blog post, I would like to discuss the definition of what a system is and show how to create a system context diagram, define the system boundary, and thus find a clear answer to the question “what is my system?”
Definition of the term system
Let's start with a definition of the term "system." There are various sources that provide more or less similar definitions of the term system.
| source | definition |
| INCOSE Systems Engineering Manual V.3.2.2-de (International Council on Systems Engineering) |
A group of interacting elements organized to perform one or more predetermined tasks. |
| Wikipedia | A system (from ancient Greek: σύστεμα sýstēma, "a whole composed of several individual parts") is generally defined as a collection of elements that are related or connected to one another and interact in such a way that they can be viewed as a unity with a specific task, meaning, or purpose, as a structured, systematic whole. In various disciplines, more specific uses of the term are proposed, discussed, and applied. |
| ISO26262 | A set of elements (system elements), at least sensors, processing units, and actuators, that are related to each other according to a design. Note: A system element can also be a system itself. |
According to DIN EN 60601-1, the following system definitions apply to medical technology.
| Medical electrical system (ME system) | Combination of individual devices, as defined by the manufacturer, of which at least one must be ME equipment and which are connected together by a functional connection or by the use of a multiple socket-outlet. |
| Programmable Electrical Medical System (PEMS) | ME equipment or ME system containing one or more programmable electronic subsystems (PESS). |
| Programmable Electronic Subsystem (PESS) | System based on one or more central processing units, including their software and interfaces. |
|
|
| Dipl.-Ing. Goran Madzar, Partner, Senior Systems Engineer E-mail: madzar@medtech-ingenieur.de Phone: +49 9131 691 240 |
|
Do you need support with the development of your medical device? We're happy to help! MEDtech Ingenieur GmbH offers hardware development, software development, systems engineering, mechanical development, and consulting services from a single source. Contact us. |
|
Gain an overview through system context
As a systems architect, one of my first tasks is to model the system context. To do this, I create a diagram with all the systems and people involved. At this point, I may go far beyond my area of responsibility. Even if I am only responsible for one component of the system, I still need the system context. Only if I know all the systems involved can I clearly distinguish which system I will consider in the future and which I will not. Furthermore, the system context reveals important interfaces to the other systems that need to be considered. My recommendation is to record an overall overview for each system as a system context. I then carry out a system boundary. This means that I only assume responsibility for part of the overall system in the further process. All specifications and development results are created for the parts that lie within the system boundary. For me, the system boundary thus clarifies the question: "What is inside and what is outside?" This question is very important and helpful. It allows me to define the interfaces at the system boundary in the next step. For example, a system may have a mains supply as its input. It's clear that the device doesn't contain a power supply. Therefore, the mains supply is external, and the power supply forms the system interface. The device may also transmit data to a hospital network. I don't want that within my system either. Therefore, the data interface to the hospital network forms the interface of my system. Since errors in system design usually occur at system boundaries, it's important to specify the interfaces precisely.
Carry out system demarcation
As we've already seen, the definition of the system boundary isn't fixed. How should one determine where the system boundary should be? To clarify this question, I've formulated a few guidelines that can help with the definition.
Which systems can be operated independently of each other?
If one system can be operated independently of another, then the two systems should be considered separately.
Minimizing interfaces
When defining the system boundary, care should be taken to keep the interfaces at the system boundary as small as possible. This reduces complexity and testing effort at the system level.
For which subsystem or system do I take responsibility?
This is a key question. The system boundary also defines your area of responsibility. Therefore, you shouldn't include parts for which you cannot or do not want to assume responsibility. This is often the case with contract developments. A supplier or the development department can only assume responsibility for the system they developed themselves. This makes it all the more important to clearly define the area of responsibility and communicate this responsibility clearly to the other stakeholders in the project.
What should be allowed together and what should be allowed separately?
Ask yourself which parts you want to allow individually and which parts you want to allow as a system. Parts that are allowed separately can also be modeled separately.
Chronological sequence in development
If one subsystem already exists and the other is yet to be developed, then this makes sense to consider the subsystems separately. The same applies if development is not to take place simultaneously.
Modeling with a SysML tool
For this, I use Enterprise Architect and model the system context in SysML. You can also draw the system context on a whiteboard, flipchart, or PowerPoint. The tool isn't that important. The figure below shows the system context for a very simple system.
And how do you verify all of this?
That's a very good question. After all, you've broken down a system into various subsystems, each of which has been specified and verified individually. Of course, you also need to verify and validate the entire system. This can be based on the marketing requirements or the overall system specification. This should enable you to view the entire system, consisting of its various subsystems, as a whole and examine its requirements.
My tip:
Create a diagram with the system context of your system and discuss it with your colleagues. You'll get a lot of feedback, from "I've never seen the system like this before" to "But doesn't this and that also belong to the system?" And that's a good thing. Discuss your ideas and define the system boundary together.
If you need support in creating a system context diagram or would like to define the system boundary within a workshop, please contact me. I would be happy to help you gain clarity about your system.
More information on medical electrical systems can be found in Stefan Bolleininger’s podcast in episode 9 medical electrical systems.
I welcome feedback and would love for you to contact me. Feel free to leave a comment on the article. If you know someone who might also be interested in the blog, I'd be very happy if you would recommend it.
Best regards
Goran Madzar