Event Chains for End-to-End Latency

When reviewing the architecture documentation of a typical project today, modules and components are still described in hierarchical structures. Communication relationships are little more than a line between boxes. However, to support domain and zonal architectures, functions will be distributed across multiple ECUs. Static architecture designs cannot reflect the impact one function in an ECU will have on another, nor what might happen as they share a bus for data communication at any moment in time. As a result, end-to-end interaction of these functions are not reflected as properties of the system, and no effort is made to ensure their correctness in quality management.

The timing for an end-to-end event chain is derived from a safety standard, such as Euro NCAP. For example, in an emergency brake assist system (EBA), the time available for the sensor-to-actuator path is the total time derived from the standard minus the time required for vehicle deceleration.

This result is then broken down further into the timing for the sensor to deliver data, the ECU to process the data and trigger the actuator, and the actuator to respond. Finally, the time available for the ECU can be broken down further, defining how much time is available for each processing stage within the ECU. For an EBA, this will include sensor post-processing, arbitration, rating, planning, and vehicle control steps.

Similar to the manner in which process models highlight end-to-end value chains for businesses, event chains deliver similar insights for automotive systems engineers. They describe causal relationships between components of the static architecture in the context of a concretely required system response. This means the significance of the relevant processing steps for the system response is explicitly represented. As a result, for each end-to-end function, it is clear which role or contribution a concrete component must provide.

Without event chains, the function developer remains unable to answer simple questions that are central to operational correctness. There is also no ability to pre-determine the impact of changes, such as reassigning a function to a different ECU or core of a multicore system.

There are three essential pieces of information this approach delivers:

• With what urgency should I be treating this data compared to the other data over which I have responsibility,
• How important is this data with respect to the other ongoing processing tasks,
• And what dependencies exist between this task and others on this processor, on this ECU, and on other ECUs.

Using this approach, it is quickly possible to determine the age of data entering function blocks and compare them with others. It is also clear what upstream function blocks are dependent on this information. Finally, clear temporal limits, defining ‘whens’, coupled with ‘from whom’ and ‘to whom’ knowledge, helps when problem solving and changes are necessary.

Today’s most complex automotive electronic systems are already struggling with latency throughout the system, both between individual components and end-to-end, from sensor to actuator. The concept of event chains forces the development team to consider, starting at the highest level, beyond functional networks and get into the causal relationships of logical processing steps. This decomposition of networks enables the definition of timing requirements, allowing latency to be added as a dashboard key performance indicator (KPI).

Dashboards can also integrate many other essential system properties, providing a more comprehensive overview at all times. Processor utilization, slack time, net execution time, process execution including response time, and end-to-end latency and jitter become metrics that can be discussed daily. The teams who can help are immediately obvious if any red flags appear. Thanks to the event chain timing budgets, it is immediately clear where a timing problem originated, allowing measures to be taken at earlier project stages.

Event chains deliver value in all development phases, from defining the system architecture to delivery of the product. Each event chain has a concrete start event that is used as a reference point for all further temporal and causal considerations. Then, at every step in the chain, the causal dependency between processing steps is described.

Stakeholder requirements, which usually only exist in text form, can thus be broken down into concrete, machine-evaluable event chain requirements. Important system properties thus become transparent throughout all development phases. And, with software updates over the lifetime of the vehicle also required, this approach will deliver even more value and time savings.

Using event chains, any design changes during the project only requires a handful of what-if analyses to assess their potential impact. Hardware is also better utilized, and there are more opportunities to find and implement optimizations. Finally, as the software is reused for new vehicle platforms, moving it to new processors and hardware platforms becomes significantly easier.

Project managers also benefit from the application of event chains in the following ways:

• Transparency – it is clear what is expected and, when something goes wrong or a failure is found, it is apparent who can resolve it.
• Early detection and resolution – issues relating to temporal problems typically hide in projects until everything is integrated. By testing for them from the beginning, they can be found and resolved much earlier.
• Increased efficiency – no-one likes meetings, and less so when blame is being apportioned. Event chains help to focus minds and encourage collaboration, as everyone has the same context around the issues.
• Decoupling of architects and function managers – Architects can focus on system architecture and not unravelling the reasons why specific functions are working as expected.

Sharing event chain requirements with all project stakeholders also ensures they have the information they need to work independently, increasing project efficiency.

Event chains are identified on the basis of stakeholder requirements for the required system behavior. As each chain is defined, it must be broken down into individual steps as required, and specifications formed. Once defined, fulfilment of the requirements must also be integrated into the testing process. Such compliance must be monitored at all levels, and applies to both internal and external stakeholders.

This approach works best when individuals are given responsibility for their event chains. As a rule, each person responsible for a function has an overview of their event chains. They won’t specify how to implement the function to fulfil the event chain requirements, but they will determine the steps that must be achieved, and the boundary conditions under which they must be fulfilled.

INCHRON supports you when defining, implementing, and resolving challenges related to event chains. This process start by supporting automotive system architects and function manager. Starting with the most important event chains, we gradually delve deeper, extending them across the project in a systematic manner. Using our chronSUITE and chronFINITY software, coupled with our consulting engineers, you’ll also be able to store the details of the event chains following your preferred development process.

Our tools will also ensure you have a complete overview of the status of all event chains. You can monitor the impact of changes at all levels of abstraction and across ECUs. This also include trace analysis and model simulation. Systematic test case design is also part of this process, ensuring you’re the first to know when an issue has arisen.

If you’d like to know more about event chains and how INCHRON can support you and your team, please schedule a meeting with us.