1、_ SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising there
2、from, is the sole responsibility of the user.” SAE reviews each technical report at least every five years at which time it may be revised, reaffirmed, stabilized, or cancelled. SAE invites your written comments and suggestions. Copyright 2017 SAE International All rights reserved. No part of this p
3、ublication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) Tel: +1 724-776-497
4、0 (outside USA) Fax: 724-776-0790 Email: CustomerServicesae.org SAE WEB ADDRESS: http:/www.sae.org SAE values your input. To provide feedback on this Technical Report, please visit http:/standards.sae.org/AS5506/3 AEROSPACE STANDARD AS5506/3 Issued 2017-08 Superseding AS5506/2 Annex D Architecture A
5、nalysis and Design Language (AADL) Annex D: Behavior Model Annex RATIONALE This Architecture Analysis and Design Language (AADL) Annex D: Behavior Model Annex standard document was prepared by the SAE AS-2C Architecture Description Language Subcommittee, Embedded Computing Systems Committee, Aerospa
6、ce Avionics Systems Division. The purpose of the Behavior Model Annex is to enable modeling of component and component interaction behavior in a state-machine based annex sublanguage. The Behavior Model Annex language was originally published as AS5506/2 in 2011. The language addresses a number of e
7、rrata and improvements to align with the AADL V2.2 core language AS5506C published January 2017. These errata and changes have been approved by the committee. The Behavior Model Annex was originally published as part of AS5506/2, a volume of three annexes. In the future, each published Annex to AADL
8、 has its own number starting with the revised Behavior Model Annex as AS5506/3. SAE INTERNATIONAL AS5506/3 Page 2 of 37 TABLE OF CONTENTS Annex D Behavior Model . 6 Annex D.1 Scope 6 Annex D.2 Overview Of Behavior Annex Concepts 6 Annex D.3 Behavior Specification. 8 Annex D.4 Thread Dispatch Behavio
9、r Specification . 15 Annex D.5 Component Interaction Behavior Specification . 19 Annex D.6 Behavior Action Language 23 Annex D.7 Behavior Expression Language 29 Annex D.8 Synchronization Protocols 34 Figure 1 Sender behavior specification . 18 Figure 2 Client server behavior . 36 SAE INTERNATIONAL A
10、S5506/3 Page 3 of 37 FOREWORD (1) The AADL standard was prepared by the SAE Avionics Systems Division (ASD) Embedded Computing Systems Committee (AS-2) Architecture Description Language (AS-2C) subcommittee. (2) This AADL standard defines a Behavior Model Annex that extends the AADL core language AS
11、5506C with a state machine-based sublanguage annex notation for specifying component and component interaction behavior. SAE INTERNATIONAL AS5506/3 Page 4 of 37 INTRODUCTION (1) The SAE Architecture Analysis and Design Language (referred to in this document as AADL) is a textual and graphical langua
12、ge used to design and analyze the software and hardware architecture of performance-critical real-time systems. These are systems whose operation strongly depends on meeting non-functional system requirements such as reliability, availability, timing, responsiveness, throughput, safety, and security
13、. AADL is used to describe the structure of such systems as an assembly of software components mapped onto an execution platform. It can be used to describe functional interfaces to components (such as data inputs and outputs) and performance-critical aspects of components (such as timing). AADL can
14、 also be used to describe how components interact, such as how data inputs and outputs are connected or how application software components are allocated to execution platform components. The language can also be used to describe the dynamic behavior of the runtime architecture by providing support
15、to model operational modes and mode transitions. The language is designed to be extensible to accommodate analyses of the runtime architectures that the core language does not completely support. Extensions can take the form of new properties and analysis specific notations that can be associated wi
16、th components and are standardized themselves. (2) AADL was developed to meet the special needs of performance-critical real-time systems, including embedded real-time systems such as avionics, automotive electronics, or robotics systems. The language can describe important performance-critical aspe
17、cts such as timing requirements, fault and error behaviors, time and space partitioning, and safety and certification properties. Such a description allows a system designer to perform analyses of the composed components and systems such as system schedulability, sizing analysis, and safety analysis
18、. From these analyses, the designer can evaluate architectural tradeoffs and changes. (3) AADL supports analysis of cross cutting impact of change in the architecture along multiple analysis dimensions in a consistent manner. Consistency is achieved through automatic generation of analysis models fr
19、om the annotated architecture model. AADL is designed to be used with generation tools that support the automatic generation of the source code needed to integrate the system components and build a system executive from validated models. This architecture-centric approach to model-based engineering
20、permits incremental validation and verification of system models against requirements and implementations against systems models throughout the development lifecycle. (4) This document contains a revised version of the Behavior Annex, that enables modeling of component and component interaction beha
21、vior in a state-machine based annex sublanguage. SAE INTERNATIONAL AS5506/3 Page 5 of 37 INFORMATION AND FEEDBACK (1) The website at http:/www.aadl.info is an information source regarding the SAE AADL standard. It makes available papers on AADL, its benefits, and its use. Also available are papers o
22、n MetaH, the technology that demonstrated the practicality of a model-based system engineering approach based on architecture description languages for embedded real-time systems. (2) The website provides links to three SAE AADL related discussion forums: The SAE AADL User Forum to ask questions and
23、 share experiences about modeling with SAE AADL, The AADL Toolset User Forum to ask questions and share experiences with the Open Source AADL Tool Environment (OSATE), and The SAE Standard Document Corrections and Improvements Forum that records errata, corrections, and improvements to the current r
24、elease of the SAE AADL standard. (3) The website provides information and a download site for the Open Source AADL Tool Environment. It also provides links to other resources regarding the AADL standard and its use. (4) Questions and inquiries regarding working versions of annexes and future version
25、s of the standard can be addressed to infoaadl.info. (5) Informal comments on this standard may be sent via e-mail to errataaadl.info. If appropriate, the defect correction procedure will be initiated. Comments should use the following format: !topic Title summarizing comment !reference AADL-ss.ss(p
26、p) !from Author Name yy-mm-dd !keywords keywords related to topic !discussion text of discussion (6) Where ss.ss is the section, clause or subclause number, pp is the paragraph or line number where applicable, and yy-mm-dd is the date the comment was sent. The date is optional, as is the !keywords l
27、ine. (7) Multiple comments per e-mail message are acceptable. Please use a descriptive “Subject” in your e-mail message. (8) When correcting typographical errors or making minor wording suggestions, please put the correction directly as the topic of the comment; use square brackets to indicate text
28、to be omitted and curly braces to indicate text to be added, and provide enough context to make the nature of the suggestion self-evident or put additional information in the body of the comment, for example: !topic cCharacter !topic its meaning is not defined SAE INTERNATIONAL AS5506/3 Page 6 of 37
29、 Annex D - Behavior Model Normative Annex D.1 Scope (1) This Behavior Annex provides a standard sublanguage extension to allow behavior specifications to be attached to AADL components. The aim of the Behavior Annex is to refine the implicit behavior specifications that are specified by the core of
30、the language. The Behavior Annex targets the following goals: Describe the internal behavior of component implementations as a state transition system with guards and actions. However, the aim is not to replace software programming languages or to express complex subprogram computations. Extend the
31、default run-time execution semantics that is specified by the core of the standard, such as thread dispatch protocols. Provide more precise subprogram calls synchronization protocols for client-server architectures. (2) The Behavior Annex includes the definition of the Behavior_Specification AADL an
32、nex subclause that is used to describe internal behavior and run-time semantics extensions and the Behavior_Properties property set that defines a property for subprogram call protocols. This document is organized as follows: Annex D.2 gives a short overview of the annex Annex D.3 defines the syntax
33、 and semantics of the state automaton used for the Behavior_Specification annex sublanguage. Annex D.4 defines the syntax and semantics of the dispatch condition language used to specify the conditions for a thread dispatch that are a refinement of the default thread dispatch conditions specified in
34、 the core AADL standard. Annex D.5 defines the syntax and semantics of the interaction operations used to specify the component interaction with other components through its port, subprogram, and data access features. Annex D.6 defines the syntax and semantics of the action language used to specify
35、the transition actions of the automaton. Annex D.7 defines the syntax and semantics of the expression language used in the various parts of the behavior annex. Annex D.8 provides details about the behavior of subprogram call synchronization protocols defined by the Subprogram_Call_Protocol property.
36、 Annex D.2 Overview of Behavior Annex Concepts (1) The Behavior_Specification annex sublanguage expresses state transition systems with guards and actions. The behaviors described in this annex must be seen as specifications of the actual behaviors: they can therefore be non-deterministic. They are
37、based on state variables whose evolution is specified by transitions that can be characterized by conditions and actions. The action language can make use of all the visible declarations that are described in the encompassing AADL specification. When such an annex is defined in the scope of a compon
38、ent type declaration, then it applies as a default behavior to all the implementations of that type. SAE INTERNATIONAL AS5506/3 Page 7 of 37 (2) The state transition system of a Behavior_Specification consists of a collection of states and transitions between the states. The state automaton has one
39、initial state, from which the automaton behavior starts. The state automaton also has one (or more) final states. When a final state is reached the behavior is considered to have terminated. The state automaton can have complete states that represent temporary suspension of execution and resumption
40、based on external trigger conditions. Finally, the state automaton can have transitory execution states. (3) These state transition systems can be used to specify the sequential execution behavior of an AADL subprogram, the dispatch, mode, input, and output behavior of AADL threads or devices, the p
41、rotocol behavior of AADL virtual buses and buses, the dynamic behavior of a process or system, etc. The behavior from the initial state to a final state typically represents the execution behavior of a subprogram with one or more return points. The behavior of a component such as a sampling periodic
42、 thread or a thread processing commands, may start in an initial state; initialize itself and suspend itself at a complete state; reactivate from the complete state repeatedly based on time or the arrival of an external event or message; transitioning from the initial state to the first complete sta
43、te, or between complete states may involve transitioning to intermediate execution states; a termination request results in a transition to a final state. (4) The transitions of a state transition system specify behavior as a change of the current state from a source state to a destination state. A
44、condition determines whether a transition is taken, and an action is performed when the condition evaluates to true. Transition priorities control the evaluation order of transition conditions, thus, the transition to be taken if the conditions of multiple transitions hold; otherwise the transition
45、choice is non-deterministic. Transition conditions fall into four categories: conditions that affect the execution of a thread based on external triggers (dispatch conditions); conditions that model behavior within an execution sequence of a thread, subprogram or other component (execute conditions)
46、 and are based on input values from ports, shared data, parameters, and behavior variable values; conditions that abstract the behavior of a component when detecting internal events; conditions that abstract the behavior of a component when receiving external events that do not represent dispatch co
47、nditions (e.g., mode switches). (5) The timed dispatch protocol of the core AADL standard specifies a timeout condition for dispatches relative to the previous dispatch. The Behavior_Specification allows the modeler to define dispatch timeout conditions relative to the previous completion as well as
48、 timeout conditions on blocks of behavior actions. Furthermore, the Behavior_Specification allows modelers to specify what behavior is to occur when such timeouts occur. (6) When a component is specified in the core AADL model to have modes, then the Behavior_Specification supports the specification
49、 of mode-specific behavior. (7) A subprogram call is an external trigger to the state transition system of a subprogram. The arrival of events and event data on ports of an non-periodic thread is an external trigger for dispatching the thread; it initiates a transition in the hybrid state automaton defined in the AADL core standard AS5506C, 5.4.1 as well as the state transit
