Specify time budgets
This use case is about how to divide an overall end-to-end delay into smaller segments, in order to specify how big portion a component (or subcomponent) in the path between stimulus and response may take.
Relationships
Main Description

Problem statement

A driver generally has certain expectations on the reactivity of the vehicle he is driving. For example, it would not be acceptable to wait for 5 seconds for the doors to unlock after he has pressed the key. A more acceptable time limit would be 1 second. The main characteristic of this example is that the time limit refers to a stimulus from and to a response to the environment of the system. Such time limits, hereafter called end-to-end delays (or requirements), are specified based on a user’s perception with respect to certain functionality.

In a design, the data and control flow paths between a stimulus and a response generally go through several components. Each path delimited by a stimulus and a response that relate to the environment are called end-to-end event chains. The components in the end-to-end event chain are to be implemented by different suppliers or in-house development teams. It therefore has to be clear for each such supplier or team exactly how big portion of the total end-to-end delay is available for the component that they implement.

A similar situation occurs when a control algorithm needs to impose a maximum age on its sensor input data. In that case, an event chain is defined from sensor to the input of the control function. This type of time budgeting and the one mentioned previously are handled in a similar way methodologically, but requires a different use of TADL notation due to the need of a slightly different semantics (reaction vs. age). The following description will not make a clear distinction between these two types of time budgeting.

Following from the above, time budgeting is about dividing an overall end-to-end delay into smaller segments, in order to specify how big portion a component (or subcomponent) in the path between stimulus and response may take.

Overview

An end-to-end delay generally originates from either an explicit or implicit user requirement or expectation, or from control performance needs. Other sources of end-to-end delays are legislation, standards or legacy. The methodology described here focuses on how to distribute such an end-to-end latency over the components and subcomponents in the end-to-end event chain.

At the same time with this top-down segmentation of the end-to-end delay, another part of the development project starts with defining hardware, software platforms and other low level details. Legacy functions are also already being introduced. All this means that there is already early in the development process detailed information about the final solution that could be useful when assigning time budgets. Thus, it is beneficial to also introduce a bottom-up flow of timing information for the purpose of time budgeting. This will reduce the number of design iterations. A major issue is how to handle this mix of bottom-up and top-down information. Figure 1 illustrates the main idea of time budgeting.

For example, on vehicle level, a requirement may postulate that “The doors shall be unlocked not later than 1 second after a valid transponder key has been recognized”. This requirement specifies the end-to-end delay that is to be segmented over the end-to-end event chain on the various abstraction levels.

Since the operational level is the lowest abstraction level, time budgeting is not performed at this level. It only serves to feed the bottom-up flow with measured execution data, and to verify that no task execution times in the final implementation exceed the time budgets specified on implementation level.

 

Figure 14 - The principles of time budgeting

The time budgeting process contains, in addition to the above, clear elements of negotiation between OEMs and suppliers, as well as exchanging timing models between the different parties. For this reason, it is heavily encouraged to combine the time budgeting process with the processes proposed in the use cases Negotiate time budgets and Exchange models.