In this chapter, based on a comprehensive understanding of the term mechatronics, the meaning of embedded systems (in the narrower sense microcontroller solutions) and selected engineering techniques are discussed.

Compared to mechanical engineering, electrical engineering, but also electronics and computer science, mechatronics is a very young subject. The emergence of this technical domain is due to the structure of modern systems that emerged from the 1980s. Until then, there was a very clear distinction between mechanical, electrical, electronic, optical, pneumatic and hydraulic systems. This was then also reflected in the training. Often one still encountered “pure” systems such as completely mechanical solutions. Electro-mechanics had been recognized as a separate specialist domain for a long time due to the frequently encountered electro-mechanical systems. However, electronics and computer science are increasingly permeating all modern system designs. In Germany, for example, in the 1990s one had to recognize that a separation between vehicle electrics, electronics and mechanics was no longer appropriate. Today there is no longer the profession of car electrician or car mechanic. There are only vehicle mechatronics engineers left. The car as a mechatronic system is just one example. This trend can be transferred to all modern systems. This mutual penetration of the technical domains has accelerated significantly since then. Today, mechatronic systems are increasingly networked and integrated into the Internet, so that we now speak of cyber-physical systems. Internet of Things, digitization, Industry 4.0, smart home, smart city, etc. are ultimately different perspectives on one and the same object. Modern systems are complex structures of overlapping subsystems from different specialist domains. These system approaches only work in the interplay of the various specialist domains and achieve completely new quality features.

A specialist domain plays a special role in this. The increasing shift (displacement / dependency / …) of the functionality of modern system solutions into the (from) the software domain can be observed.

The microcomputers which play a central integrating role in modern mechatronic systems can be roughly divided into two categories. On the one hand, central control solutions in which the microcomputer (computer) can usually be recognized by the presence of a display and perhaps also a keyboard or other computer-typical input and output devices. On the other hand, there are often decentralized, hidden, embedded microcomputers whose presence cannot be seen by the viewer of the system. Such embedded microcomputers are often so-called microcontrollers. Microcontrollers are a special category of microcomputers; these are also called single-chip microcomputers. With microcontrollers, all elements of a complete computer (arithmetic unit, control unit, memory, input and output devices, etc.) are integrated on an integrated circuit (chip). This means that extremely little circuitry is required to integrate microcontrollers into a system. Microcontrollers can therefore be very easily embedded in systems.

In the German language there is a specific word for the, often very competent, artful and deeply the human soul satisfying production of an object without prior planning, i.e. purely from the thoughts, ideas and the production process itself, a specific word: tinker . Tinkering are sharply demarcated from the working method of an engineer. Engineers plan, calculate, design, simulate, etc. before they manufacture anything. These engineering virtues outlined in English with the term engineering naturally also apply to mechatronic systems and should also apply to the technical domain of software production.

In fact, all aspects of software engineering aim at the manageability of complexity. Let us try to sensitize ourselves to the problem of complexity. We'll do a little experiment for that. Look at the following illustrations one after the other (please cover the illustration on the right first). You should determine the number of matches presented. Do not take more than 3 seconds per picture. So it's about perceiving and understanding.

In three seconds you will not be able to give more than an estimate of the number of matches for the illustration on the left. Let's repeat the experiment with the picture on the right. You will now have the exact number of matches in much less than three seconds. Something essential distinguishes the two pictures. The number of matches in both representations is exactly the same. But only in the second picture are you able to really grasp the number with one or two glances. Why is that? On the one hand, the type of arrangement, the expert speaks of structuring, ensured that. The second aspect is that you were offered a familiar pattern, almost a kind of symbol.

This experiment can easily be developed further up to the use of abstract, unified symbols for the representation of numerical facts. The way to a uniform representation of numbers meant making complexity manageable. That is exactly the challenge of software development. The matches are the individual program lines, the picture the entire application. It is important to master both. The way leads via standardized symbols that are structured and put together to form complex statements according to the rules of a language. A standardized construction drawing of the software is created with the UML. Construction drawings are essential for the manufacture of complex systems. The notion that systems we use every day may have been made without engineering design should worry us.

As we have worked out up to here, mechatronic systems characterize the integration of:

• mechanical components
• hydraulic and pneumatic components
• electrical components
• electronic components
• and software components to form a complete system

Each of these specialist domains makes use of specific engineering techniques, in particular specific standardized construction drawings. For example:

• mechanical construction drawings according to ISO 128, ISO 5455, ISO 5455, …
• hydraulic and pneumatic construction drawings according to ISO 1219
• electrical / electronic construction drawings according to IEC 60617

The software for mechatronic systems should also be produced and documented using appropriate engineering techniques. Just as there are a multitude of norms and standards for classical engineering, there are also those for software development. ISO 19505, also known as UML, should play a special role in this course. Software should be designed, implemented and documented with some basic UML representation techniques. From the entire stock of UML, we will use the following display techniques in particular:

1. Use case diagrams to clarify WHAT the software should do (top level requirements)
2. Activity diagrams to clarify HOW the software should work (functional requirements)
3. Class diagrams to construct and document the software
4. State diagrams to construct and document the logic of the software
5. Sequence diagrams to document solitary algorithms

As the last component, ISO 19514, SysML, should complete our catalog of engineering techniques. SysML (Systems Modeling Language) is the latest engineering technology presented here. It was developed under the impression that an interdisciplinary modeling language covering the domains of mechanics, electrics, electronics, hydraulics, pneumatics and software is required. None of the domain-specific construction languages ​​is able to map modern mechatronic systems as a whole in one model. SysML offers a remedy here. It replaces previous non-standardized overview displays such as block diagrams, relationship diagrams, hierarchy diagrams, etc. SysML offers a standardized framework for the presentation of interdisciplinary aspects. SysML has adopted numerous suggestions from UML (SysML as UML profile). So we'll see a lot of similarities between UML and SysML. From the SysML we will use the following display techniques in this course:

1. Use case diagrams to clarify WHAT a system should do
2. Block definition diagrams to clarify which components a system consists of
3. Internal block definition diagrams to clarify how the components work together

This Embedded Systems Engineering course is intended to develop a broad interdisciplinary understanding and knowledge of the participants as well as to develop practical skills for the realization of embedded systems. The specific goals of the course include:

• A basic understanding of modern systems as mechatronic units and cyber physical structures
• Role of software in modern systems
• Basic understanding of the structure of embedded systems
• Raising awareness of the need for a high level of engineering in all domains
• Knowledge and skills for modeling with UML and SysML
• Knowledge and skills for the implementation of microcontroller solutions with UML and in C ++
• Raising awareness of the importance of correct documentation for modern systems

A software process is the defined sequence of activities, the agreed rules, techniques, tools and the expected results of the activities for the production of software. Defined software processes ensure the plannability, controllability and quality of results in the manufacture of software. The following simple software process is agreed as a binding workflow for this course.

The individual activities have the following expected results:

1. Requirements analysis
   1. User view as use case diagram (as SysML / UML model)
   2. required functionalities as activity diagrams (as SysML / UML model)
   3. Test cases (as a document)
   4. HRM hardware resource model (as SysML model)
   5. SRS System Requirements Specification (as a document)
2. System design
   1. Class model of the concept level / architecture model (as UML model)
   2. if necessary, state model (as UML model)
   3. System documentation (as a document)
3. implementation
   1. Class model of the realization (as UML model)
   2. Behavioral models of the realization (as UML model)
   3. Productive code (as a transferable format of the target platform, * .hex, * .elf)
   4. System documentation (as a document)
4. System integration
   1. the completed system
5. Test and handover
   1. the tested system
   2. the technical system documentation (as a document)
   3. the user documentation (as a document)

• next chapter
• back to overview