Structure

This part of the specification defines the structural constructs used in EAST-ADL. The structural view of a model focuses on the static structure of the instances of the system being modeled and their static relationships. This includes the internal structure of such instances and their external interfaces through which they can be connected to communicate with one another, by exchanging data or sending messages.<br/>EAST-ADL abstraction layers are introduced to allow reasoning about the features on several levels of abstraction. Note, however, that the abstraction levels are only conceptual; the modeling elements are organized according to the artifacts, which may span more than one of these layers. Where applicable, entities on different abstraction levels are related with a realization association to allow traceability analysis. Traceability can also be deduced from the requirements structure.<br/><br/>The EAST-ADL abstraction layers with their corresponding artifacts are:<br/>- Vehicle Level, with feature models describing decompositions of system characteristics organized as a software product line.<br/>- Analysis Level, including the Functional Analysis Architecture (FAA). The FAA is built from an abstract functional definition of the system to capture analysis support of what the system shall do, ensuring relation with features from the Vehicle layer view. There is an n-to-m mapping between VehicleFeature and Feature entities and FAA entities (i.e., one or several functions may realize one or several features).<br/>- Design Level, including the Functional Design Architecture (FDA). The FDA represents a decomposition of functionalities denoted in the FAA, including behavioral description but excluding software implementation constraints. The decomposition has the purpose of making it possible to meet constraints regarding non-functional properties such as allocation, efficiency, reuse, or supplier concerns. Again, there are n-to-m mappings by Realization relationships between entities in the FDA and entities in the FAA. Non-transparent infrastructure functionality of the AUTOSAR Basic SW Architecture, such as mode changes and error handling, are also represented at the Design Level in terms of BasicSoftwareFunctions.<br/>- The Hardware Architecture models Electronic Control Units (ECUs), communication links, sensors and actuators and their connections. The Hardware Architecture is also considered at the Analysis Level as FunctionalDevices and at the Design Level as HardwareFunctions because models of sensors, actuators, and early assumptions of hardware may be needed either for the Functional Analysis Architecture or the Functional Design Architecture.<br/>- Implementation Level refers to the System element in an AUTOSAR model.<br/><br/>The Environment contains Environment functions, which are encapsulations of plant models, i.e. models of the behavior of the vehicle and its non-electronic systems. Environment models are needed for validation and verification, from early analysis models to the implemented embedded system. Note that no specific EnvironmentFunction exists as such in the language, but DesignFunctions or AnalysisFunctions are used. However to connect such functions to the rest of the systems, special connectors are used, ClampConnectors which can traverse hierarchal containments.<br/>