Pragmatic interface design of a mechatronic system

Guest contribution by | 07.06.2021

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.


Do you need help with systems engineering, creating a system architecture or writing customer specifications? Then take a look at There you will find more information about the mentoring programme in systems engineering and the creation of customer specifications.

Bjoern Schorre has published another article in the t2informatik Blog:

t2informatik Blog: Requirements specifications in an agile environment

Requirements specifications in an agile environment

Bjoern Schorre

Bjoern Schorre

Dipl.-Ing. Bjoern Schorre is a GfSE-certified systems engineer and the operator of the Ingenieurbüro für Systems-Engineering. With 20 years of professional experience in various industries, he can analyse and optimise development processes as well as assist in the implementation of requirements specifications and architectures. Through his mentoring programme for systems engineering, he passes this knowledge on to medium-sized companies. Bjoern Schorre also helps with concrete topics such as the short-term creation of customer specifications for a new product.