Behavior : public package
Created: 2006-02-28 12:38:56
Modified: 2010-06-02 14:11:26
Project:
Advanced:
<p>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/></p><p><br/></p><p>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: only one behavior is active at any point in time and is not preemptable.<br/></p><p><br/></p><p>A FunctionBehavior in EAST-ADL is mainly a reference point to some description provided elsewhere in a tool-dependent format, as depicted in the diagram for the behavior of a function below. This enables the re-use of current behavior descriptions contained in the tools currently used by automotive companies and suppliers. Given that, requirement 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 behaviors 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/></p><p><br/></p><p>The rest of the behavioral constructs (see the following diagram of the behavior model organization) relate to the organization of the triggering of behaviors 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/></p><p><br/></p><p>The triggering of behavior itself, defined by 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/></p>
Object Type Connection Notes
Structure Package Dependency ADLBehavior -> ADLFunctionType
Timing Package Dependency  
GenericConstraints Package Dependency  
Requirements Package Dependency