FunctionBehavior represents the behavior of a particular FunctionType - referred to by the association to FunctionType. What is meant by behavior is a transfer function performing some data computation (in case of FlowPort interaction) or an operation that can be called by another function (in case of ClientServer interaction). The representation property indicates the kind of representation used to describe the behavior (see FunctionBehaviorKind). The representation itself (e.g., defined in an external model file) is identified by a URL String in the path property. If the representation is provided in the same model file as the system itself, the path property is not used. It is merely a placeholder for the purpose of containing information about and links to the external behavioral model.<br/><br/>FunctionBehavior may refer to execution modes by the association to the element Mode. This is not mandatory; however, when provided, the relation indicates the list of execution Modes in which the FunctionBehavior can potentially be executed (see element Mode).<br/><br/>The triggering of a FunctionBehavior is unknown to the behavior. It is defined by FunctionTriggers (see this element).<br/><br/>Note that the association between FunctionBehavior and FunctionType is specified as a one-way navigable link from FunctionBehavior to FunctionType: what this means is that the EAST-ADL language specification does not require a FunctionType be aware of the FunctionBehavior it is assigned to. Only the navigation from behavior to function is mandatory; the implementation of a reverse link might however be provided depending on the tool support.<br/><br/>Although each FunctionBehavior can refer to at most one FunctionType, note that several FunctionBehaviors can refer to the same FunctionType. In this case, when a FunctionType has several behaviors, only one behavior shall be active at any given time instant, i.e., no concurrent behaviors are allowed in EAST-ADL functions. For instance we cannot have one active behavior in Simulink and one in Modelica. Both can be referenced in the same function, but at any given time, only one is executable. Conditions such as modes and variability must prevent two behaviors being potentially active at the same time.<br/><br/>Note also that FunctionBehaviors are assigned to FunctionTypes and not to FunctionPrototypes. This means that among a set of FunctionPrototypes, which share the same type, behaviors are also shared. However when a FunctionBehavior refer to Modes, which are referred to by different FunctionTriggers, different triggering conditions can be provided among a set of FunctionPrototypes for the same set of behaviors - see FunctionTrigger.<br/><br/>In the case where the identified FunctionType is decomposed into parts, the behavior is a specification for the composed behavior of the FunctionType. <br/><br/><br/>Semantics:<br/>The semantics of FunctionBehavior follows the semantics of the behavioral representation/tool used (for instance SIMULINK, ASCET, etc.). However, in relation to the EAST-ADL model, the FunctionBehavior has synchronous execution semantics:<br/><br/>1. Read inputs from input ports<br/>2. Execute behavior with fixed inputs (run to completion)<br/>3. Provide outputs to output ports<br/><br/>The data transfer between the EAST-ADL ports and the FunctionBehavior is representation/tool-specific and considered part of the execution of the FunctionBehavior.<br/><br/><br/>Notation:<br/>FunctionBehavior appears as a solid-outline rectangle with "Behavior" at the top right. The rectangle contains the name. <br/><br/><br/>Extension: Behavior<br/>
