Behavior

This chapter describes the behavioral constructs of the EAST-ADL language. What we mean by behavior here is either a function performing some computation on provided data (FlowPort interaction) or the execution of a service called upon by another function (in a ClientServer interaction).<br/><br/>The execution of the behavior assumes a strict run-to-completion, single buffer-overwrite management of data. That is, each execution starts with the reading of data, which are not stored locally and are constantly replaced by fresh data arriving on ports. The function then performs some calculation and finally outputs some data on the output ports. The execution is non-concurrent within an elementary function: only one behavior is active at any point in time. Among a set of functions, behavior is fully concurrent, except for timing precedence constraints. This is to avoid making assumptions that are not met at Design and Implementation Levels. Design Level: All functions are as concurrent as hardware design allows. Timing precedence constraints may constrain this further.<br/><br/>A FunctionBehavior in EAST-ADL is mainly a reference point to some description provided elsewhere (outside the EAST-ADL model) in a tool-dependent format, as depicted in the diagram for the behavior of a function below. This enables reuse of current behavior descriptions contained in the tools currently used by automotive companies and suppliers. Given that, requirements and traceability information can be provided for behavior in relation to the rest of the EAST-ADL model. A list of typical tool formats is provided as an enumeration, FunctionBehaviorKind. Depending on the EAST-ADL language implementation, such a behavior description can be provided in the model itself; for instance, when using a UML implementation of the EAST-ADL, UML behavior modeling can be used. Yet, it should be noted that the behavior described shall be compliant with the execution semantics of an EAST-ADL function.<br/><br/>The rest of the behavioral constructs (see the following diagram of the behavior model organization) relates to the organization of the triggering of behavior attached to functions. At a high level one can define activation Modes, which may span across the whole architecture. Such Modes can be regrouped in exclusive sets. Whenever a FunctionTrigger or a FunctionBehavior refers to a Mode, this means its activation is dependent on the Mode being active or not. Thus, different execution configurations can be defined.<br/><br/>Triggering of the behavior itself, defined by the FunctionTrigger, can be either time- or event-based and be either type-wise or prototype-wise to allow further adjustments of functions in a particular context. Events and timing constraints are defined in the Timing, Events, and TimingConstraints sections.<br/>