I want both: low CPU load and low E2E Latencies

"All functions are ok now - we just need it to be faster." Everyone has heard this before and we all know how hard it is to improve the performance of a system towards the end of a project. In our experience, the system / hardware / software architecture defines the limits of performance. Some things may be improved in implementation and integration, but the big things are set during architecture phase. Making the right decisions in the architecture & design phase ensures that performance requirements are met and avoids late changes.

Real-time systems - both big and small - have to find an optimal balance between CPU load and end-to-end latency. Either you put all software on one core and avoid communication or you distribute software load to multiple cores, but introduce communication overhead. Communication overhead also means extra latency. If your system has critical latency requirements for data flows, it is wise to find a good distribution of software loads while maintaining the maximum latency requirements. It is the job of the system and software architects to design for an optimal real-time behavior and manage real-time requirements.

A model-based simulation approach supports architects in exploring design alternatives. In early project phases performance requirements can be checked and the system can be optimized. During the project the same requirements can be applied to the implementation and integration in order to ensure, that the architecture is implemented correctly.

This talk discusses the value of model-based design and optimization of the dynamic architecture.

Go to Session

Timing, Scheduling, Latencies - Model Based Approach to Design, Optimization, Analysis and Test

You will learn how to

• Optimize your embedded timing before you code
• Find nasty sporadic issues 12 months earlier
• Collaborate on requirements across teams

Go to Session

Live Q&A - Timing, Scheduling, Latencies - Model Based Approach to Design, Optimization, Analysis and Test

Live Q&A with Olaf Schmidt for the theatre talk titled Timing, Scheduling, Latencies - Model Based Approach to Design, Optimization, Analysis and Test

Go to Session

Tips and Tricks for Avoiding and Fixing Real-Time Issues (2020)

Today embedded systems are made up of a large number of hardware parts, SoC, CPU and networks. On the software side many layers of large software stacks, API and applications are used. The complexity of the systems is ever increasing. Most people set their focus on getting the multitude of functional requirements done. Functional requirements are what the customers sees in the first line.

But, hey, there are also temporal requirements in many use cases. Users expect a certain reaction time of their system. They don't care about complexity, well defined interfaces or big amounts of data being transferred. Press a button and immediately see a light switch on. In an autonomous vehicle the required time from recognizing an obstacle to making the decision to turning the steering wheel is only milliseconds. The requirements describe end-to-end timing in many cases. Data coming from an input has to be at output within a certain time. We call the data flow "event chain".

This talk will take you on a journey through a model-based approach. Using a model to design the system and its timing behavior has the big advantage, that it can be used in simulation. The simulation runs the model and shows the timing behavior of all components, busses, scheduling, end-to-end timing and so on. It is possible to try out different scenarios quickly and find the best configuration. In the talk we will look at both the system view and the device view. They have to be synchronized and contribute to the overall user experience. On the way timing requirements are formalized, evaluated and violation is reported. Timing requirements for individual parts of the systems like cores and software components can be derived from the model and simulation.

After determining the best configuration teams will spread out and start the implementation. Trace files, that contain the timing of the implementation are taken. The traces are tested against the timing requirements already defined in the design step. The adherence to all timing requirements can be check upon every step in the projects. Upcoming problems are found early.

Join me in the exciting journey of flashing the light of a car within the expected time.

Go to Session