Basics of the development of embedded systems

Wikipedia defines an embedded system as follows:

An embedded system is an electronic calculator or computer that is integrated (embedded) in a technical context. In this context, the computer either performs monitoring, control, or regulating functions, or is responsible for some form of data or signal processing, for example in locking or unlocking, encoding or decoding, or filtering.

Embedded systems can be found in most devices in all industries today. Often these systems perform critical and security-related functions and must therefore be designed and developed with great care.

The context of an embedded system is defined by the user, peripheral system, and physical environment, as shown in Figure 1.

When the term system is used in the following article, this refers to an embedded system.

Building Embedded Systems

A system consists of hardware and software that are perfectly matched, as shown in Figure 2.

Hardware

The hardware of a system can vary greatly depending on the intended use. It consists of, among other things:

• Microprocessors
• Memory (Flash, RAM, EEPROM, etc.)
• FPGAs (Field Programmable Gate Array)
• Sensors
• Actuators
• Power supply
• Discrete logic (logic gates, etc.)
• Ports
• Control elements, display, etc.
• Casing

 

An embedded system contains one or more microprocessors. These allow the behavior of the system to be controlled by software. Microcontrollers (System on a Chip, SoC) are also frequently found in embedded systems. Here, the microprocessor and other components such as memory and peripherals are housed on a single chip. In the following, the term microprocessor is used, but this also includes microcontrollers.

 

Software

Software that runs on a microprocessor is called firmware. In contrast to a classic desktop application, firmware must make do with significantly fewer resources and performance.

A firmware consists of the following components:

• Bootloader
• Operating system
• Application

The bootloader is executed when the microprocessor starts up. It is responsible for loading and starting the application software and, if necessary, the operating system.

The operating system provides basic functions such as multitasking, memory management, and other services. Embedded operating systems are often referred to as Real-Time Operating Systems (RTOS) to indicate their real-time capability. (See also next chapter).

Not all firmware uses an operating system. If an operating system is not used, it is called bare-metal firmware. Often a library called ‘runtime’ takes over the basic function of a mini operating system. The runtime is usually linked directly to the application and downloaded to the device with it.

The application is started by the bootloader or the operating system and is responsible for the actual function of the embedded system. It often accesses processor interfaces directly in order to communicate with the hardware of the embedded system and thus indirectly with subsystems and the user.

 

Interfaces

Embedded systems communicate with other systems and/or the user via interfaces. There are also many embedded systems without user interfaces that communicate solely with other systems.

i) System Interfaces

Various interfaces are used for communication with other systems. These can be standardized interfaces such as UART (Universal Asynchronous Receiver Transmitter), I2C (Inter-Integrated Circuit), CAN (Controller Area Network), or USB (Universal Serial Bus). Proprietary interfaces are also encountered frequently. These are mainly used within a device and consist of data lines that connect microprocessors to each other or to other hardware components. In contrast to standardized interfaces, these are often faster and cheaper to implement.

ii) User Interfaces

If the embedded system supports interaction with a user, it also has interfaces for this. These are also referred to by the umbrella term User Interface (UI), Man Machine Interface (MMI) or Human Machine Interface (HMI).

Such interfaces can include screens, keypads, touchscreens, etc. However, many devices also have LCDs, LEDs, buttons, switches, and similar controls. Audio input and output can also be part of such an interface, e.g. for alerting.

 

Limitations and Requirements

Compared to PC applications, embedded systems are subject to various restrictions and requirements:

• Finite Resources
• Limitations of Libraries and Tools
• Real-time Capability
• Security and Reliability
• Limited Update/Maintenance Capability

 

Finite Resources

In contrast to a PC application, firmware must make do with significantly fewer resources. A typical microprocessor usually has a clock speed of a few to a few 100 MHz. Usually, only a few kilobytes (KB) are available as working memory and a few megabytes (MB) as persistent memory. This is mainly due to the fact that the manufacturing costs of embedded systems usually have to be kept as low as possible because high quantities are produced, and in the mobile sector energy efficiency is also a very important factor. In contrast, more powerful PC hardware has significantly higher power consumption, generates more heat, and is more expensive to produce.

With a clean system and software architecture, however, it is possible to take this aspect into account and only use as many resources for a task as necessary. If it is clear early in the design process what is best solved where in the system, unnecessary ‘consumers’ are avoided, reducing both manufacturing and development costs.

 

Limitations of Libraries and Tools

When developing firmware, there are often no extensive libraries available in the development environment. Therefore, the required algorithms may have to be implemented by hand. This must also be taken into account during planning and implementation, as it can increase the development effort.

Code generators and 3rd party libraries can reduce this effort.

 

Real-Time Capability

Another important aspect of an embedded system is its real-time capability. Real-time means that a certain operation must be carried out in a precisely defined time window. This can be in the range of seconds or even microseconds.

It is important to clearly define what time limits apply:

• When must the operation be completed?
• What is the tolerance?

 

With this information, the system design can be tailored to the requirement. For example, more powerful microprocessors often have mechanisms such as caching or branch prediction that improve performance. However, this means that it is no longer clear in advance exactly how long an operation will take to complete. If the data is already in the cache, it is faster; if it has to be loaded first, it takes longer.

This means that when selecting and configuring a microprocessor, care must be taken to ensure that it can meet the time requirements. If this has to be solved later in the software, the development effort can increase massively.

 

Security and Reliability

Many embedded systems have to perform safety-critical functions or are critical for the function of an important device/process (mission critical). Therefore, safety is an important aspect in the development of such a system.

Safety requirements must be considered early in the development process:

• Functional reliability
• Behavior in the event of an error
• Data security (cybersecurity)

 

A risk analysis (see below) helps to identify these requirements at an early stage. Applicable standards and guidelines for the corresponding equipment class and industry also provide a framework for this.

If security is incorporated into the design from the outset, the development effort can often be greatly reduced and security improved by cleverly dividing up components.

For example, it can be easier if external hardware monitors compliance with a parameter (voltage, temperature, etc.) and triggers a fail-safe state than to solve this in the software afterward.

When designing the system, it should be clearly defined from the beginning what the behavior should be in the event of an error.

Some examples are:

• Reset the processor and restart the firmware
• Load a backup configuration
• Remaining in a fail-safe state and maintaining critical functions (e.g. ventilation)
• Unnecessary alerting of users and/or subsystems

 

Limited Update- / Maintenance Capability

An embedded system may be difficult or impossible to update after it has been placed on the market. For example, the device often has no internet connection or no interfaces that allow a firmware update. This increases the importance of verification and validation.

Maintenance should have already been considered in the definition phase. Clear design and good test coverage can also help reduce the need for bug-fix updates.

 

Embedded System Engineering

When developing an embedded system, care must be taken to include the special requirements and limitations described above. As with any system and software development, a systematic and structured approach according to an established development process is recommended.

The procedure can be roughly divided into the following phases:

• Definition
• Analysis and Specification
• Development
• Integration and Verification
• Validation
• Maintenance

Definition

In this phase, all functions of the system to be developed should be defined. In practice, it has proven useful to clearly number and version each definition from the beginning. Once a number has been set, it should not be changed. In this way, the definitions can subsequently be clearly referenced in the following phases. It is advantageous to use a requirement engineering tool. Writing the definitions in a Word or Excel document seems easier at the beginning, but it will lead to more work later on. The definition should include the following requirements:

• Intended use
• User interface
• Peripheral systems

 

Analysis and Specification

Once the system is clearly defined, the next phase is to record the functional requirements. These are to be clearly numbered, as already mentioned in the definitions. Requirements should reference which definitions they cover.

Once the requirements are clear, the system architecture is created. This should be done holistically according to the top-down approach and take into account both hardware and software. The architecture breaks the system down into peripheral systems and these in turn into components. The interfaces between the components must also be clearly defined. Furthermore, the requirements implemented with each component and interface should be referenced. In the architecture description, it is also advisable to number and version all design artifacts, ideally with the same tool that was used for the definition and specification.

The specification should include the following requirements:

• Interfaces to peripheral systems
• Temporal behavior
• Power consumption/battery runtime
• Security
• Life expectancy

 

The chosen design should be able to meet all requirements while keeping manufacturing costs low. Therefore, the existing hardware resources must be used optimally. The lifetime of components (e.g. write cycles for flash and EEPROM) should also be considered.

Interface names should be unique throughout the design (system, electronics, software diagrams, and documentation) to avoid confusion. It is also advisable to use a naming system that is permissible for variable names in the selected programming languages (no special characters, no number at the beginning of the name).

 

Development

The system can be realized once the requirements and the design have been determined. Here, the individual components are first developed individually, then integrated into the peripheral system, and finally into the complete system.

Requirements or the design often change during implementation, so it is very important to follow a clearly defined change management so that the requirements and design documentation always match the actual implemented system. The individual components should have already been verified before integration (see below), ideally with automated tests. Verification of assemblies can be omitted in favor of verification of the system. However, it is often easier to test fault cases on components, as they may no longer be simulated in the system.

 

Integration and Verification

It must be ensured that the implementation of the components corresponds to the previously defined design. Therefore, the individual components are verified against the requirements. The integrated components, peripheral systems, and the fully integrated system should also be verified during integration.

 

Validation

The system should then be validated against the definitions to ensure that it can meet them. Automation of tests can also pay off here. However, the initial effort is not negligible, but should more than pay off in the maintenance phase.

 

Maintenance

Once the system is developed, it is used productively. Errors are often found and new requirements emerge. To take them into account, the system is often adapted and expanded during its lifetime. Here it is recommended to use an established process for change management. The V-model is often run through again here. It is important that the requirements and design are kept up to date in this phase as well. If this was properly documented during development, it would pay off here through lower costs and fewer adaptation errors.

When making adjustments to the design, close attention must be paid to ensure that no existing requirements are violated. If hardware components have to be replaced, it is important to ensure that the system continues to meet all requirements.

 

Embedded System Engineering in Medical Technology

If an embedded system is being developed for a regulated field like medical technology, there are several additional aspects to consider:

• Risk Management
• Traceability
• Comprehensible Design

 

Risk Management

Based on the system design and definition, a clearly defined process, e.g. ISO 14971, must be used to assess all risks that may arise when using the embedded system. Unacceptable risks must be reduced with appropriate measures. This can have a significant impact on the design of the system, so an initial risk assessment must be carried out during the specification phase and risk management must be kept up to date throughout the development process.

 

Traceability

In a regulated field, it is necessary to be able to show at any time where in the design which requirement was implemented and how it was tested. It is essential to use a requirement engineering tool for this. This is because creating a traceability matrix by hand is possible, but very time-consuming and error-prone. Furthermore, it will no longer be correct after the first change (see Maintenance above) and will need to be updated again.

 

Comprehensible Design

The system design must be comprehensible. Therefore, it must be documented. It is also important that design decisions and reasons are documented so that they can be understood later, e.g. during the maintenance phase.

Developing good and safe embedded systems is a challenge for any company and its developers. But with a well-planned approach and good documentation, this can be mastered and both the costs and the quality targets can be achieved.

Embedded systems have specific limitations and requirements such as:

• Finite Resources
• Limitations of Libraries and Tools
• Real-time Capability
• Security and Reliability
• Limited Update/Maintenance Capability

 

As a result, they need a clearly defined design and must be well documented and tested, as subsequent adjustments can be expensive.

In a regulated field, there are further aspects to consider:

• Risk Management
• Traceability
• Comprehensible Design.

 

IMT can advise and support you in all phases of the life cycle of embedded systems. We have successfully implemented numerous embedded system projects in medical technology and for other device manufacturers.

Do you have any further questions? Then please get in touch with us.