Pragmatic interface design of a mechatronic system
Many people know architecture from building a house. Without architecture, no house can be built. The architecture determines how large the excavation pit should be and which room should be built where. It is the same with mechatronic systems: Without system architecture, the development domains can only guess which subsystems are needed. In the construction of a house, however, the architecture mainly focuses on the structure of the building. In the context of a mechatronic system, architecture goes beyond the representation of the purely static interrelationship of the sub-elements. Many different interfaces must be considered, represented and possibly specified.
In most cases, the architecture of a mechatronic system arises from the functions that a system has to fulfil and the assignment of these functions to logical elements. By defining the logical elements of a system, the static architecture is created. Static because system elements have a fixed relationship to each other. The connections between the functions of the system elements represent the internal interfaces of the system, through which substances, energies or information are exchanged. The external interfaces are also found in this step because the system must interact with the environment in some way.
Target audiences need different levels of detail
Not everyone involved in the development of a system is interested in every detail of the architecture. Therefore, it is important to prepare presentations in a target audience-oriented way. A look at the stakeholder analysis shows which target audiences a system has. There you will find employees from the areas of sales, product management, project management but also the management. All these groups of people are far from being concerned with details such as the structure of protocol contents of an interface. Rather, the sales department must be able to explain to the customer which features of an interface will be realised and which will be available in a later version. On the other hand, the employees from the development domains are necessarily very interested in the details and also involved, since it is here that the decisions are made on how interfaces are to be realised.
An important aspect in the architectural design of mechatronic systems is the level of detail. I often ask myself the following questions during the design process:
- Are the third-party systems to be connected in the environment of my own system to be considered as well, is a large box sufficient for my own system or do system-internal subsystems also have to be represented?
- Is a simple relation between two elements sufficient for understanding or must it also be shown which system element offers the interface and which system element uses it?
If you are faced with such questions, you should focus on understanding, because not every detail needs to be included in the interface diagram, especially since most functions are nowadays already documented in the many available standards.
Interface design tips
There are some tips that are useful in interface design:
Pragmatic and simple in a team
The first steps in creating the system architecture should definitely be done in a team. To do this, it is advisable to start very pragmatically and use a pencil on the flipchart or whiteboard to create the first sketches of the system for all participants to see. In this way, the many different perspectives on the system can be immediately absorbed and refined during the journey through product development.
The discussions in the team promote understanding of the meaning and benefits of the interfaces. Often, interfaces are even found that an individual employee would not have found.
Keep reuse in mind during modelling
The next step is to convert the first sketches into a digital form using a suitable modelling tool. Only then is there a chance to reuse these representations as an image or perhaps even as a model, to make changes to them and to publish them again.
Without a digitalisation of the results, the architecture is sketched anew at every meeting. New interfaces are discovered, others are omitted or the semantic equality of interfaces is overlooked. In the further course of the development process, this leads to interfaces not being realised at all or being planned twice.
Use existing specifications and standards
Not every interface has to be specified by the system architect or the development team. By referencing existing specifications from standardisation bodies, there is a chance that known system elements can be used to realise the interfaces. This starts with the Schuko or CEE plug and ends with the software modules for protocol stacks such as Bluetooth or PROFInet. In this way, new interfaces can be integrated quite quickly and new functionalities can be realised. This procedure supports decisions regarding “make or buy” and at the same time reduces the risk of undesirable developments with the associated time delay.
Assign interface IDs
IDs are more unique than names. Therefore, the system’s interfaces should be numbered consecutively. Keep IDs for at least the lifetime of the system, ideally even beyond, as this promotes the modularity of the system. By using IDs, the name of an interface can be changed without breaking the references to that interface and its specification in the realisations.
Detail where necessary or where there is ambiguity
Finding and recording the interfaces and connections of a system, i.e. documenting their existence, is perhaps the most important step. Once all interfaces have been found by the participants in the workshop, the specification gaps regarding the interfaces can be identified. The number of interfaces that still need to be specified should be prioritised in order to determine the interfaces that could pose the greatest risks during implementation. These interfaces should be specifically worked out in detail so that clear specifications can be made for the specialist domains in order to make the integration of the system elements easier later on.
Allow for changes
Many systems change during the development process and sometimes afterwards. This also affects the interfaces. The design process must be prepared for these changes, as well as for new or changed requirements. The system architecture must therefore be designed in such a way that the changes that are accepted can be incorporated with as little effort as possible.
Contents of an interface specification
In a company, an interface specification should also exist for each interface. Either it serves as a container for references to the applicable standards or contains the proprietary details of the interface.
In general, it should be noted that all aspects that make up an interface must be found. This includes first and foremost the mechanical structure, followed by the details of substances and the respective quantities or the type of energy transmitted. The interfaces of information technology must also contain information on the protocol units.
Depending on the level of detail of the interfaces in the system architecture, different amounts of information are contained in a specification. In the order mentioned above (substances, energy, data), standards can also be referred to most readily. The more specific the information that an interface must transmit, the fewer standards exist for it. Here are three examples:
- For the specification of the PROFInet interface of one’s own system, only a minimum of effort is necessary, since the technology is largely known.
- When reading out inverter data via Bluetooth, on the other hand, you have to reference the underlying BT standard and the profile used, and also describe the protocol units you have defined yourself.
- And when developing a new internal high-speed network for the exchange of process data, you must specify all the above-mentioned levels.
Developing a system without a suitable architecture is a risk you should avoid at all costs. Finding and specifying interfaces is especially helpful when it comes to encapsulating functions and modularising the architecture of the system. With good architecture and interface design, individual system elements can be replaced, corrected or improved later in the product life cycle. This supports purchasing in the selection of purchased parts, reduces testing efforts and lowers the risk of expensive misdevelopment in the long run.
If you need help with the topic of systems engineering and the creation of a system architecture, please visit https://bjoernschorre.de. There you will find more information on the mentoring programme in systems engineering and the creation of specifications. If you don’t have the time to create a customer specification yourself, Björn Schorre will be happy to help you: https://bjoernschorre.de/lastenheft-erstellen/
Dipl.-Ing. Björn Schorre ist von der GfSE zertifizierter Systemingenieur und Betreiber des Ingenieurbüro für Systems-Engineering. Mit 20 Berufsjahren in verschiedenen Industriebranchen kann er Entwicklungsprozesse ebenso analysieren und optimieren wie auch bei der Umsetzung von Anforderungsspezifikationen und Architekturen mitarbeiten. Über sein Mentoring-Programm für Systems Engineering gibt es dieses Wissen an Unternehmen des Mittelstands weiter. Björn Schorre hilft auch bei konkreten Themen wie der kurzfristigen Erstellung von Lastenheften für ein neues Produkt.