Problem statement
A vehicle offers many different features to the driver, such as braking, steering etc. Today, these features are typically implemented using both mechanical and electronic components. The fact that the electronic system of the vehicle is integrated with different mechanical solutions implies that the vehicle electronic system inherently contains a certain degree of parallelism. That is, the system needs to monitor and control several simultaneous sources of input and output. Quite often it is also the case that the input or output needs to be synchronized in order to provide a notion of simultaneity. For example, when braking, it is crucial that the brake forces that are applied at each wheel also are applied at the same time. A correct behavior is governed by the introduction of synchronization constraints during the vehicle design. Thus, this use case deals with the formulation of synchronization constraints and how they are refined during the design.
This use case only addresses the problem of synchronization of events, regardless the order in which they occur.
Overview
According to the timing constraint logic of TADL, the synchronization constrain is specified as follows: given a set of events and given an occurrence of any event in this set, then all the other events of the set must occur at least once within a certain temporal window. Such a temporal window is called tolerance.
Since the synchronization constraint deals with time delay between event occurrences, at a first glance it may look similar to the use case “Specify Time Budgets”. However, the main difference relies on the concept of generic sets of events versus the concept of event chain used by the “Specify Time Budget” use case. An event chain is a particular set of two events composed by a stimulus and a response. A generic set of events is composed by any number of events, for which their nature of stimulus/response is not necessarily characterized. This implies that while the two events of the event chain are ordered with respect to time (the response occurs after the stimulus), a generic set of events can be composed by an arbitrary number of events for which is not defined an order relationship. Moreover, the events of a generic set of events may not have a characterization in terms of stimulus/response.
To give more insights about this constraint, we go through some examples. For instance, consider the adaptive cruise control system in a passenger car. An adaptive cruise control system takes the decision of the torque that must be applied to each wheel based on the information on the current vehicle speed and on the current distance to the vehicle in front. To compute the correct torque value, the controller requires the received information at least to represent the environment at the same time instant. This means that the events “pick the current vehicle speed” and “pick the distance to the front vehicle” must occur at the same time. It is then required synchronization between these two. To compute the correct torque value, it is also required that the information picked by the sensors arrives to the controller within a certain time delay. Such an additional requirement can be accommodated by using the “Specify Time Budget” use case considering for example the events “pick the current vehicle speed” and “the information is available at the controller input” as an event chain (note that such events represent a stimulus and a response). Finally, to design a correct braking system, we also want the four wheels to stop at the same time when a braking action is performed. Hence, the set composed by the four events “stop wheel” related to each wheel must be also synchronized.
From this example several interesting properties arise that allows us to give a comprehensive understanding of the synchronization constraint in a more general framework. In the example, we need first a synchronization constraint over the set of the two events “pick the current vehicle speed” and “pick the distance to the front vehicle”: despite this set has dimension two, it does not represent an event chain being the events two stimuli. Second, we need a synchronization constraint over the set of the four events “stop wheel” associated to the four wheels of the car: such a set of events has dimension four, and all the events can be classified as responses. Finally, for both the aforementioned sets of events is not important the order in which the elements of each set occur. In summary, according to the TADL description of this use case, synchronizing the events corresponds to impose a tolerance on each set of event.
The full function of the adaptive cruise control at the presented level of abstraction is realized by combining two synchronization constraints together with an end-to-end delay constraint, that represent the maximum time allowed between the brake pedal pressure occurrence and the car stop occurrence. However, in both the defined generic sets of events no ordering is required, while in the end-to-end delay constraint an ordering is implicitly defined through the stimulus and the response of the event chain. We remark that is not difficult to think about functions that may require a certain order of several events occurrences in addition to some synchronization constraints. In such cases, the synchronization constraint must be used in combination with some ordering constraint.
According to the EAST-ADL development phases, such generic sets of events may become richer, or new generic sets of events that must be synchronized may appear. For instance, consider the braking system of a passenger car as example, and consider the following feature provided at the Vehicle Level stated as: ”stop the car within 500ms after a brake pedal pressure occurrence has been detected”. In this statement it is easy to locate two events that are one stimulus and one response (“brake pedal pressure occurrence” and “stop the car”), and an end-to-end time delay constraint (“500 ms”) that can be accommodated with the “Specify Time Budget Constraint” use case. Let us consider the same

Figure 1 - Refinement and identification of new sets of events. At the abstraction level n the set S1 is composed by two events. After a refinement of the solution at the abstraction level n-1, the set S1 is composed by three events, and a new set of events (S2) that must be synchronized is identified.
use-case at the Analysis level. Such a feature can be stated as:”Stop simultaneously the four wheels within 500 ms after a brake pedal pressure occurrence has been detected“. The difference of the statements at the Vehicle Level and at the Analysis Level relies on the number of events that must be taken into account. In the first case, as the events are defined, it is possible to locate a stimulus and a response that occur in series, while in the second statement the events “The wheel X has stopped”, where X is front-left, front-right, rear-left and rear-right, are four responses that we want to occur at the same time, disregarding the order in which they occur. Hence, it is possible to specify a synchronization constraint over such a set, by setting the tolerance equal to zero as specified by the requirement “simultaneously”. The example shows how moving from the Vehicle Level to the Analysis level a new set of events that require synchronization has been detected. Nevertheless, there can also be cases in which a set of events for which a synchronization constraint has been defined, may increase its dimension when moving along the abstraction levels. In this case it is enough to include the new events in the generic set and apply the tolerance on the new set.
|