Research Article A Comprehensive Formalization of AADL with Behavior Annex

In safety-critical ﬁelds, architectural languages such as AADL (Architecture Analysis and Design Language) have been playing an important role, and the analysis of the languages and systems designed by them is a challenging research topic. At present, a formal method has become one of the main practices in software engineering for strict analysis, and it has been applied on the tools of formalization and analysis. The formal method can be used to ﬁnd and resolve the problems early by describing the system with precise semantics and validating the system model. This article studies the comprehensive formal speciﬁcation and veriﬁcation of AADL with Behavior annex by the formal method. The presentation of this speciﬁcation and semantics is the aim of this article, and the work is illustrated with an ARINC653 model case study in Isabelle/HOL.


Introduction
In safety-critical domains such as avionics, aerospace, automotive, and defence, a latent software error even can give rise to catastrophic consequences. Such systems have to be carefully designed and analyzed according to some strict standards such as DO-178C [1], which stipulates analysis, testing, and certification activities. Formal methods have become the recommended practice in the safety-critical fields. Formal methods are special techniques based on mathematics and are suitable for the description, development, and verification of software and hardware systems. By applying formal methods to software and hardware designs, it is hoped that, like other engineering disciplines, appropriate mathematical analysis can be used to improve the reliability and robustness of designs. In the design of computer software systems, formal verification means that mathematical methods can be used to prove their correctness or incorrectness according to one or some formal specifications or attributes. eorem proving, program analysis, and model checking are the main branches of formal verification. To be formally verified, systems should be firstly specified with a specific formalism. AADL (Architecture Analysis and Design Language) [2] is a modeling standard used in safetycritical software engineering to describe the structure of systems, such as a package of software components, which is mapped on an execution platform. AADL adopts formal modeling concepts for the description of software and hardware architecture, so that it is often used to design and standardized by the SAE, and its second version was published in 2009 and revised in 2017; for its analyzability and extensibility, AADL has become one of the popular languages within architectural modeling in the industry [4]. AADL has been studied in several projects for different modeling, analysis, simulation, compilation, extension, and formal verification. Moreover, the AADL semantic can be extended via user-defined properties and annexes.
However, AADL cannot be directly generated into the executable code, which is reliably used in safety-critical systems. So how to compile AADL to the C code is our final goal. Although there is not any comprehensive compiler or method from AADL to C on the open-source platform so far, there is some existing related work about the verified compiler or transformation of model languages like Lustre [5], CompCert [6]. As we do, proving the correctness of general-purpose compilers is undeniably a related problem, and fortunately, this work [7] encourages us and presents the possibility of development based on the model-driven design in prover tools. We aim at exploring a formal method of compiling AADL to C-like language, so we firstly limit our survey to work that focuses on the particularities of AADL.
e AADL provides a sufficient syntax and semantic to describe an embedded real-time system based on software/ hardware components and their relations. Dealing with such rich models accentuates the need for model analysis and verification. Unfortunately, AADL is a textual and graphical language, which means it is a semiformal modeling language. It lacks formal specification and semantics, and this severely limits both unambiguous communication among model developers, and the development of simulators and formal analysis tools, so itself cannot be directly used for formal verification. In this work, we choose Isabelle/Isar/ HOL [8], a tool suite (within its functional language) that gathers specification, validation, and verification of AADL and models, and also the code generation towards AADL runtime C-like language for the future work. e Isabelle/ Isar language provides a readable grammar and a convenient way to produce the proofs.
In this article, we provide an approach for the formal verification of behavioral AADL models. In detail, this article makes the following contributions: (i) Different from transforming AADL into other formal model languages, our work takes an approach by formally specifying AADLs, its corresponding models of definitions, lemmas, and proof structures necessary to verify the model, providing a blueprint for performing similar work in any prover tool. Also we can state and prove a correctness relation between the source and target semantic models, and even directly build on the compilation project in Isabelle/HOL as our future work.
(ii) We consider the AADL focusing on safety-critical software, so our work mostly covers the whole AADL elements including components, communication among components, and Behavior annex defined inside, and also supports the key features and properties. e considered AADL subset consists of both software and hardware AADL components with complex state transitions being comprehensive and that can be used in more realistic applications. (iii) We perform formal validation and verification of the AADL model and specify the critical properties. Specifically, we (1) analyze and summarize the description for the AADL standard defined by the SAE republished in 2016 and take 47 significant details into account as the grammar rules in Isabelle/HOL; (2) exploit the comprehensive semantics including Behavior annex, read, Process, and System, and then integrate them into a whole model execution semantics; and (3) perform formal instantiation, validation, and verification of three realistic AADL models.
In this context, we aim at the comprehensive formal specification and verification of AADL core language (software part) with its Behavior annex. e remainder of this article is organized as follows: in Section 2, we describe the concept of AADL along with its Behavior annex and Isabelle/HOL, and also present the strength of Isabelle/HOL and its specification language to justify why we choose it to model AADL and Isabelle/HOL to perform formal analysis; Section 3 overviews our approach including the AADL elements we selected; in Section 4, we present the syntax of our selection and the validation rules for grammar in Isabelle/ HOL; In Section 5, we present the semantics of selection and the verification, and in addition, we present the semantics of Behavior annex; Section 6 then presents a case study; and Section 7 gives the conclusions and future directions.

AADL and Its Behavior
Annex. AADL is a textual and graphical language used to model, specify, and analyze architectures (included software and hardware part) of safetycritical and real-time embedded systems, and it has been studied in several projects for different purposes analysis, code generation, extensions, and formal verification. AADL is based on a component-centric model, and it defines the system architecture as a set of interconnected components that hierarchically describes the interfaces, the implementations, the properties, and the channels among components. It describes a system as a hierarchy of software and hardware components and offers a set of predefined component categories as follows: (i) Software components: data, subprogram, subprogram group, read, read group, Process, and their types, implementations, features, connections, properties (ii) Execution platform components (hardware components): processor, memory, bus, and device (iii) System composites: they represent composite sets of software and execution platform components (iv) Annex subclauses: they allow annotations expressed in a sublanguage to be attached to the component According to the component categories, AADL software component elements are composed and synchronized to form the whole software system. Figure 1 gives an overview of the AADL software components containing essential constructions.

Isabelle/HOL Notations.
Isabelle/HOL (the full name is Isabelle/Isar/HOL, Isabelle is often for short) is a generic interactive theorem prover for implementing logical formalisms of a specification and verification, and it is the specialization of Isabelle for HOL (higher-order logic) [9]. Isabelle is implemented in ML [10]. is has influenced some of Isabelle/HOL's concrete syntax Isabelle/Isar [11], an extension of Isabelle, which hides the implementation language almost completely. Based on a small (meta)-logical inference kernel, Isabelle's LCF-style architecture ensures very high confidence about its soundness as a theorem prover. Since our whole work focuses on the verification of formalization and the output, moreover, also will invoke the theorem prover's code generator and run the test suite on the C-like code generated by itself in the future, Isabelle is used to prove the methodology in this work. is work mainly restricts itself to the core of Isabelle (simply typed Lambda calculus with ML-style polymorphism and inductive datatypes). e main notations used in this work are explained as follows: theories, working with Isabelle means creating theories. Roughly speaking, a theory is a named collection of types, functions, and theorems, much like a module in a programming language or a specification in a specification language. In fact, theories in HOL can be either. e general format of a theory T is theory T imports B 1 . . . B n begin Declarations, definitions, and proofs end where B 1 . . . B n are the names of existing theories that T is based on and declarations, definitions, and proofs represent the newly introduced concepts (types, functions, etc.) and proofs about them. lemma, this command starts the proof and gives the lemma a name. As a result of that final done, Isabelle/ HOL associates the lemma just proved with its name. Lemma, theorem, and rule are used interchangeably for propositions that have been proved. base types, in particular bool, the type of truth values, and nat, the type of natural numbers. type variables, denoted by 'a, 'b, etc., like in ML. datatypes, the general form of a datatype definition looks like this: da tatype ( ′ a 1 , . . . , ′ a n )t � C 1 " τ 1 , 1" . . ."τ 1 , n 1 " | . . . |C k " τ k , 1 " . . ." τ k , n k " It introduces the constructors C 1 : : τ 1 , 1⟹ . . . ⟹τ 1 , n 1 ⟹( ′ a 1 , . . . , ′ a n )t and expresses that any value of this type is built from these constructors in a unique manner. records, introduces a new record-type scheme by specifying its fields, which are packaged internally to hold up the perception of the record as a distinguished entity. A record of Isabelle/HOL covers a collection of fields, with select and update operations. Here is a simple example: record point � Xcoord:: int Ycoord:: int In this work, we choose a deep embedding method, which does not try to directly represent elements of the language as expressions of the target language (in this case: Isabelle/HOL), but rather encodes them.

Approach Overview
e general methodology of our work is given as follows: at first, we select a comprehensive core AADL with its Behavior annex and a policy for modeling as 3.1.1 and 3.1.2 presented; secondly, we define a specification from AADL in Isabelle/ HOL and model an example; next, we determine some significant rules about AADL grammar from AADL official standard manual and transform them into the modelchecking functions, and then, we present a validation by using these functions; finally, we present the semantics of the comprehensive core AADL and verify some properties (reachability, trace refinement, etc.) by the semantics in Isabelle/HOL. e main idea of our methodology is illustrated in Figure 2.

Selection of AADL
3.1.1. Selection of Core AADL in is Work. In this article, our work focuses on the specification and analysis of the software components of systems, and most of execution platform components in AADL (virtual processors, memory, buses, virtual buses and devices, etc.) are not under consideration except the processor (simply discussed). Moreover, the group, prototype, and refinement are regarded as a set element, and mainly for the reusability of the AADL code, software systems can be modeled even without these elements; therefore, they are not accounted in this work. is selection of AADL core elements is comprehensive and sufficient to specify and model an embedded system on the software side.
A component can be a subcomponent of the other component. us, the following components are supported: processor, data, subprogram, thread, process, system, and thread's Behavior annex. A processor component is an abstraction of hardware and software that is responsible for scheduling and executing threads that are bound to it. A data component represents a data type and also static data in the Scientific Programming   Figure 2: Approach overview. 4 Scientific Programming source text. A subprogram component represents sequentially executed source text that is called with parameters. A thread component is a schedulable unit that is declared within a process component and can be executed concurrently with other threads. A process component represents its virtual address space, and a software system represents an assembly of interacting application software. A feature is a part of a component definition that specifies how that component interfaces with other components in the system. Features consisted of port, access, and parameter in our work. In addition, features can be combined with properties, and our work can support some temporal and queuing properties, such as Dispatch_Protocol (periodic, sporadic, timed), Period, Queue_Processing_ Protocol (FIFO, LIFO), Queue_Size, Elapsed_Time, Exe-cution_Time, and Scheduling_Protocol.
A connection is a linkage between features of two components representing communication of data and control between components. Our work supports connections between port connections, parameter connections, dataaccess connections, and subprogramaccess connections.
A property provides information about model elements, and it has a name, a type, and a value. Each property has a value or list of values that is associated with the named property in a given specification. Our work focuses on the indispensable properties, which depend on the specific components.

Selection of AADL Behavior annex.
e Behavior annex document provides a standard sublanguage extension to allow behavior specifications to be attached to AADL components. It is an important part of AADL, as it split a whole system model into several single composable components to make design and analysis easier. e Behavior annex of a Behavior annex instance is defined on the vocabulary consisting of its private variables behavior_variable, its states behavior_state, and ports of its parent component. Its transition system is the union of the transitions specified by a behavior_transition. A Behavior Annex specification of a thread contains variables, states, and transitions. e states may be initial, complete, execution, or final.
Our work can support the Behavior annex with its specification to enrich the running model. e aim of the Behavior annex is to refine the implicit behavior specifications that are specified by the core of the language. Yet we practically state that behavior specification subclauses can only be added in a thread, and the behavior specification subclauses describe the thread that the behavior specification subclause belongs to, since the execution of the whole system at one processor is actually the execution of one thread.

Related
Work. AADL lacks formal specification and semantics; therefore, it cannot be directly used for formal verification and it is often transformed into several formal model languages to be adopted with existing formal analysis tools. We study several formal approaches on AADL. According to the transformation method and the consideration of the AADL model with or without Behavior annex, these are grouped into three categories. e first category is often based on model transformation into different languages without (or barely with) Behavior annex such as Petri nets [12], Timed automata [13], TLA+ [14], Lustre [15], Fiacre [16], and CSP [17,18]. ese approaches are contented with the AADL semantic described in its standard, which is enough to formally simulate the system and verify a set of behavioral properties. e second category represents work about the model transformation of AADL with its Behavior annex such as BIP [19], Signal [20], TASM [21,22], and Ocarina [23]; for example, Ref. [19] defines a transformation into the BIP language, and then, the BIP model is transformed into nontimed models to enable model checking and simulation with the BIP framework.
e third category almost only specializes in behavior and analysis by using and mapping AADL behavioral models such as IF [24] and real-time Maude [25]. Such a mapping allows the analysis of the performance and the dependability.
ese AADL formal approaches mainly consider different AADL subsets (with or without annexes) and carry on formal verification with existing tools such as UPPAAL, Tina, and Polychrony.
ey often define a model transformation to implement whole AADL model certification instead of AADL itself. Moreover, a formal proof of the semantics preservation of the transformation has not been considered by them. Our work considers several resource information in the transformation, and the theorem prover is used to prove the methodology, that is, the correctness of the translation. e comparisons of the above-related works are listed in Table 1. ese works focus on a subset of the AADL, and most of the related works only consider a small subset of Behavior annex. For AADL elements, our work supports Behavior annex and components, in which variables, states, state transitions of Behavior annex and connections, features, and software components of components are represented by a "+". For the aspect of verified properties, our work considers more types of properties by Isabelle, for example, grammar, reachability, and trace refinement. e main goal of our work is to contribute to a better integration of the formal techniques in a compilation process. So this article is full of formal approaches revolving around the AADL, and we choose Isabelle/Isar/HOL [8], a tool suite (within its functional language) that gathers specification, validation, and verification of AADL and models, and also the code generation towards AADL runtime C-like language for the future work. Besides the tool suite that can be used as stand-alone compiler, the Isabelle/ Isar language provides a readable grammar and a convenient way to produce the proofs.

Presentation of Abstract Syntax in Isabelle/HOL.
is section describes those aspects of components that are common to all AADL component categories. Our work provides the abstract syntax of the considered AADL in Scientific Programming Isabelle/HOL: an AADL model contains several software subcomponents (like threads), several features (like ports), and Behavior annex specification. Each Behavior annex can belong to a thread, and each thread with its Behavior annex belongs to a process. In this article, to keep the article reasonably concise, some structural elements and model attributes are expressed in a uniform abstract syntax. In addition, at the whole system level, a system is viewed as a set of processes, and a process is viewed as a set of threads in communication through port and access connections. According to the selection of AADL and its Behavior Annex, the classification of main syntax is discussed in the following subsections.

Features and Connections.
Features are a part of component type definition that specifies how that component interfaces with other components in the system. Features are specified as port, access, and parameter. Two components are connected between features by a linkage called connections, and connections can be the transmission of control and data in components' implementation. AADL supports connections between port, access, and parameter connections.
e details of Features and Connections are much more than we have space to present here, and some of them are defined in Figures 3 and 4, and the code snippets are shown in Figures 5 and 6     eir instances are presented in Figure 11.
We consider that there is only one system as a parent component in a practically running model. is results in a component containment hierarchy that ultimately describes the whole actual system as a system instance. is section defines the following categories of software subcomponents: data subcomponent, subprogram subcomponent, thread subcomponent, process subcomponent, and system component. eir code snippets in Isabelle/HOL are presented as Figures 12-16.

Behavior Annex.
As discussed in Subsection 3.1.2, a behavior specification subclause is a part of a thread, and it describes the thread that the Behavior annex belongs to. e Behavior annex is composed of variable set, state set, transition set, and its private information (like its name and ports of its parent component), and its elements are united by its transitions. A behavior_annex instance is presented in Figure 17. e transitions can describe the behavior as a statetransition system linked with guards by some conditions and actions. e behavior_transition defines a relation from a source state to a destination state and represents a sequence of actions within a thread, which can be executed once its condition is satisfied. A behavior_transiton consists of its name, source state, destination state, guard condition, and actions. e actions associated with transitions are action block. A transition instance is presented in Figure 18. e guards combined of conditions are in the transitions, which are explicitly classified as dispatch conditions and execution conditions. A dispatch condition is a Boolean expression that specifies the trigger of events. An execution condition is a logical expression on the inputs, outputs, values, and properties, or any other execute conditions. A transition instance is presented in Figure 19.
e actions can be classified as basic actions and action blocks in the transitions. e basic actions can be defined as empty (marked as NULL), assignment actions, communication actions, or timed actions. e action blocks are in the     According to all the related works above contributed to the formal specification, we define the syntax of the Behavior annex in Isabelle/HOL, and some parts are presented in Figure 21.
Notice: dispatcher is a predefined type, and it describes the hardware expression language used in the annex and is not given here; 's is a state set describing all possible values stored in ports; the action language of the annex is abstracted as a function computing outputs from the value of its input ports. e time consumption of an action is directly modeled as a time attribute.

Whole Model.
In our work, we aim at a running model for the next formal verification in a development. For this end, we define a whole system, which is described with a set of mapping between the datatypes and the configuration records in practice, and the whole system model syntax is presented in Figure 22.

Validation Rules for
Grammar. AADL is a standard defined by the SAE, and its reversion was published in 2016.
ere are numerous methods and rules of description for AADL in the new version, and they cover syntax, naming rules, legality rules, consistency rules, and standard properties, and also several discrete and temporal semantics. However, none of current tools have integrated these methods and rules to check the AADL model comparatively at present, even they do not take these rules into account, especially the rules.
record data-properties = dt-access-right :: Access-right option dt-concurrency-control-protocol :: Concurrency-Control-Protocol option record (′Port, ′Dataaccess, ′Subpaccess, ′Parameter) data-type = (′Port, ′Dataaccess, ′Subpaccess, ′Parameter) type-base + dt-properties :: data-properties option record (′Connection, ′Data, ′Subprogram, ′Thread, ′Process, ′System) data-impl = (′Connection, ′Data, ′Subprogram, ′Thread, ′Process, ′System) impl-base + dt-properties :: data-properties option   Our work integrates the rules into the theorem prover Isabelle/HOL, which come to having a partial mapping from concrete syntax to abstract model. In this section, for the next formal verification built on the firmer trust basis, our work makes a link of the validation for the AADL model in Isabelle/HOL. Firstly, since some of all the rules are mandatory and others are recommended, our work determines 47 significant rules on account of AADL selection and they are considered to be compulsive. ese rules cover software components, features, connections, and Behavior annex from the grammar perspective. Secondly, these rules R are specified as the definitions or functions by the functional language Isabelle/Isar in Isabelle/HOL as the properties needed to be validated. We specify the constraints as properties by using the function definition aim at guaranteeing the correctness of the built AADL model. And then, we abstract the element e of a realistic AADL model into Isabelle and instantiate all elements together into a concrete model M. It is mapped as a parameter of these rules definitions. Lastly, we identify the lemmas of these rule definitions and integrate into a comprehensive lemma about grammar. e correctness of the validation pass hinges on a lemma that shows the assertion: M ⊨ grammar_validate (R e) For the given lemma grammar_validate, the correctness of the validation pass is simple to state. Due to the space constraints, the segmental validation rules and definition code for grammar are classified as syntax, naming, and others (including legality, consistency, and stand properties), which are shown in Tables 2-4.

Formal Semantics and Verification
Formal semantics is a kind of mechanism based on strict and mathematical logic, which is especially important for describing safety-critical systems. Model's correctness and valid execution can be guaranteed by formal semantics. Although the AADL standard has depicted some execution semantics by natural language, it is the absence of precise dynamic semantics and even has no formal semantics at present. In addition, the AADL model cannot be executed directly because it is just an abstract description of the record process-properties = pro-period :: Time option pro-priority :: int option pro-resumption-policy :: Resumption-policy option pro-deactivation-policy :: Deactivation-policy option pro-load-exe-time :: TimeRange option pro-load-deadline :: Time option pro-startup-exe-time :: TimeRange option pro-startup-deadline :: Time option record (′Port, ′Dataaccess, ′Subpaccess, ′Parameter) process-type = (′Port, ′Dataaccess, ′Subpaccess, ′Parameter) type-base + pro-properties :: process-properties option record (′Connection, ′Data, ′Subprogram, ′Thread, ′Process, System) process-impl = (′Connection, ′Data, ′Subprogram, ′Thread, ′Process, ′System) impl-base + pro-properties :: process-properties option        system architecture. is not only restricts the possibility of formal analysis of AADL models, but cannot conduct model checking and verification. It is necessary to propose a way to specify AADL models with formal models. However, AADL is mainly a mathematical model, which cannot be used to automatically verify properties of a given AADL model. In order to provide evidence of model checking and enable the proof of semantics preservation of system running, the informal execution semantics of AADL formalized directly in Isabelle/HOL are considered an operational semantics. In this article, the AADL semantics is given an operational semantics, which is delivered from the AADL informal execution semantics and can be compared with the informal one. e main benefit with operational semantics is that it is based on a rigorous mathematical foundation and is built on the same principles as functional programming languages. Such benefits determined us to define an underlying operational semantics for AADL and its Behavior Annex, and consequently implement the verification in Isabelle/HOL.

Semantics of Behavior Annex.
e AADL model is completed with behavioral descriptions using the Behavior annex, like computation and communication for threads.
us, there is a relation between the AADL execution model and the Behavior annex. e execution model specifies when the Behavior annex is executed and on which data it is executed, while the Behavior annex acts in a thread (or a subprogram) and describes behaviors more precisely. For this purpose, the semantic specifications given as above will be enriched by the Behavior annex. Since the behavior is explicitly expressed by atomic transitions, the operational semantics of the Behavior annex is defined based on the refinement of the rule of each transition in the Behavior annex, and the execution semantics of the Transition is based on the semantics of the Actions in itself. is section begins by describing how to formalize the meaning of Behavior annex using automaton. And then, the constituents of the Behavior annex and their semantics are defined (including transition system, action and expression language, etc.).

Formalization of Behavior Annex by Automaton.
We present the formalization of a Behavior annex by using an incomplete automaton AM with several variables. e AM is used to interpret the meaning of the whole Behavior annex, and AM � (S, s0, V, P, B, T, C) is defined as     If the thread is in dispatch status, the states (initial, complete, final) of Behavior annex can be observed, as these states are specified in a transition and they can be mapped to the execution of the outside components. If the thread is under execution, the detail of states cannot be observed, as their execution states are just held in a running thread and they are the internal states related to the processor in the whole Behavior annex. So our work defines the formal execution semantics of Behavior annex as two parts: one is about transitions, and the other is about Actions in transitions. ese two parts are described by big-step semantics through a global state (shared variables), and they can be recombined to the integrated semantics of whole Behavior annex. Furthermore, the Action semantics can be mapped to some imperative language in the future work, and its formal semantics would make the preservation more clear. where "type_name_valid m ≡ (∀dt1 dt2. (data_tp m)≠None ∧ dt1≠dt2 ⟶ (type_name (the (data_tp m) dt1))≠(type_name (the (data_tp m) dt2))) ∧ (∀sp1 sp2. (subprogram_tp m)≠None ∧ sp1≠sp2 ⟶ (type_name (the (subprogram_tp m) sp1))≠(type_name (the (subprogram_tp m) sp2))) ∧ (∀thd1 thd2. (thread_tp m)≠None ∧ thd1≠thd2 ⟶ (type_name (the (thread_tp m) thd1))≠(type_name (the (thread_tp m) thd2))) ∧ (∀pro1 pro2. (process_tp m)≠None ∧ pro1≠pro2⟶ (type_name (the (process_tp m) pro1))≠(type_name (the (process_tp m) pro2))) ∧ (∀sys1 sys2. sys1≠sys2 ⟶ (type_name ((system_tp m) sys1))≠(type_name ((system_tp m) sys2)))"

Semantics of Transition in Behavior Annex.
Actually, the transition system, which is described by three sections (variable declarations, state declarations, and transition declarations mentioned in Section 4.1.4), is a refinement of the AADL Behavior annex, and it is created by linking two states using a guarded automaton. A transition (Si − [conditions] ⟶ Sj actions { }) specifies the behavior as a state change from a source state Si to a destination state Sj, which can be guarded by conditions (dispatch or execution). In this section, we specify the meaning of the elements in transition and use them to express the semantics of transition.
(1) Variables: e variables, which are temporary through the whole Behavior annex subclause, declare the identifiers that represent local variables and record intermediate results within the scope of the whole Behavior annex subclause. ey can be used to hold the values of out parameters on subprogram calls and also can hold input from incoming port queues or values read from data components in the AADL specification.
(2) States: e states, which may be mapped to the various thread states, are categorized as initial, complete, final, or execution state. e initial state means thread state halted, the complete state means thread state awaiting for dispatch (suspend or resume), the final state means thread state stopped, and the execution state means the rest of thread states (running) that are not be observable.

12
Scientific Programming calls, receiving of input and sending of output, assignments to variables, read/write to data components, or other activities.
We describe a transition as a series of atomic operation in Behavior annex, and a series of Transitions are composed into a whole behavior. As a transition is mainly supported to complete the thread component with behavior handling inputs and outputs in order to enrich the communication mechanism, so in some sense, talking about the semantics of whole transitions is about Behavior annex actually. Our work defines the semantics of Behavior annex by the operational big-step semantics presented by the automaton AM as T�(s, g, a, d), and they are defined inductively as follows: T: 's BA_Transition s, d: State a: Actions g: Conditions e core state space is denoted in terms of states by the type 's different from the state of transitions, it is polymorphic, and its semantics is augmented with control flow information in Isabelle/HOL as follows.
Where the type variable state 's is regarded as a set of variable states and related to the variable state in Actions when the execution is in a normal state Normal s. Besides, 's can hold the value of variables on inputs or outputs, and it is attached to the receiving or sending events as a message Msg s as an option.
Moreover, a transition is guarded by conditions, and conditions can be either dispatch conditions or execution conditions as shown in Figure 19. We consider a dispatch condition g of T formed by clock c as its dispatch trigger; it means the dispatch condition is presented as time trigger. An execution condition g of T is considered logical value expressions. e semantic of transition is defined inductively by the rules in Isabelle/HOL as shown in Figure 23.

Semantics of Action in Behavior Annex.
is section defines the semantics of Actions by the operational big-step semantics. Actions of the Behavior annex define actions performed during transitions. Actions associated with transitions are action blocks that are presented in Figure 20, where the single action can be defined as control structures such as basics, conditionals, and loops. e action_sequence means it is executed in order, while action_set can be executed in any order. e basic_action can be empty, assignment, communication, or time-consuming. e assignment_action is reference for the value assignment. e communicatio-n_action is reference for receiving and sending data, event, or event data on the inputs and outputs. e Timed_action is predefined computation actions.
Since this section should be related to the semantics of transitions and be a part of it, the semantics of Action is defined as Γ: : 〈s, a〉⇒d, which means in the procedure environment Γ execution transforms the source state s to the destination state d. Actually, the destination state d is the Table 4: Description and code of other rules.

Description
Code in Isabelle/HOL (1) A thread models a concurrent task or an active object, that is, a schedulable unit that can execute concurrently with other threads. Each thread represents a sequential flow of control that executes instructions within a binary image produced from the source text. One or more AADL threads may be implemented in a single operating system thread. A thread always executes within the virtual address space of a process; that is, the binary images making up the virtual address space must be loaded before any thread can execute in that virtual address space. reads are dispatched; that is, their execution is initiated periodically by the clock or by the arrival of data or events on ports, or by the arrival of subprogram calls from other threads. definition thread_thread2system_valid:: "(′s, ′Dispatcher, ′Port, ′Dataaccess, ′Subpaccess, ′Parameter, ′Subprogramcall, ′Subprogramcalls, ′Connection, ′Data, ′Subprogram, ′ read, ′Process, ′System, ′BehaviorAnnex) AADL_model ⇒ bool" where "thread_thread2system_valid m ≡ ∀sys. ∃sc1 sc2. (if ((system_im m)≠None ∧ (the (system_im m) sys)≠None ∧ (impl_subcomps (get_sysimpl m sys))≠{}) then (sc1∈(impl_subcomps (get_sysimpl m sys)) ⟶ (case sc1 of SC d _ ⇒ True | SCPro pro ⇒ (if ((process_im m)≠None ∧ (the (process_im m) pro)≠None ∧ (impl_subcomps (get_proimpl m pro))≠{}) then (sc2∈(impl_subcomps (get_proimpl m pro)) ⟶ (case sc2 of SC d _ ⇒ True | _ ⇒ False)) else False) | _ ⇒ False)) else False)" definition thread_thread2process_valid:: "(′s, ′Dispatcher, ′Port, ′Dataaccess, ′Subpaccess, ′Parameter, ′Subprogramcall, ′Subprogramcalls, ′Connection, ′Data, ′Subprogram, ′ read, ′Process, ′System, ′BehaviorAnnex) AADL_model ⇒ bool" where "thread_thread2process_valid m ≡ ∀pro. ∃sc. (if ((process_im m)≠None ∧ (the (process_im m) pro)≠None ∧ (impl_subcomps (get_proimpl m pro))≠{}) then (sc∈(impl_subcomps (get_proimpl m pro)) ⟶ (case sc of SC d _ ⇒ True | _ ⇒ False)) else False)" . . . . . .  destination state d of its transition. To connect with the automaton T, we refinement a in the automaton T as a new automaton A and reconstitute the automata T'�(s, g, true, t) ∪ A and A�(t, true, a, d) where a in A and a in the previous T are not same, and the former is the detailed implementation of the latter. T′ and A are defined by the case on Actions as follows: (iii) Empty_action of basic_action NULL can be represented as an invalid operation to the states and defined by SKIP.

Scientific
(iv) Assignment_action of basic_action v\coloneq e represents a variable state transition and it is defined by A � (t, true, v' � e, d) where v' represents the successor state of v.
(v) Communication_action of basic_action is divided into the output port action port!(e) and the input port action port?(v). e output can be defined by A�(t, true, port � e, d). e input can be defined by A�(t, true, v' � port, d) where v' represents the successor state of v.
(vi) Timed_action of basic_action computation(t1. . .tN) represents the execution time of the action block. It is specified as two ports-pb (port begin) and pe (port end), and defined by A � {(s, true, pb, i), (i, pe, true, d)}, where i is an intermediate state as a complete state and timed constraint Val(pb + t1) ≤ Val(pe + tN e semantic of Action is defined inductively by the rules in Isabelle/HOL as shown in Figure 24. e procedure environment act-body denotes the static procedure declarations as mapping from subprogram names to actions programs of Behavior annex and defines the execution of command c that transforms the initial state s to the final state t under act-body.

Semantics of AADL Components.
ere are a great number of components that can be used to build hierarchical models in AADL, and it makes AADL have a great capacity of expression. In our work, the AADL model is viewed as a set of concurrent tasks scheduled by a processor and asynchronously interacted. Generally, we consider the following components: data, thread, process, and processor. ese components are connected through AADL port connections, completed with a set of standard properties, and finally grouped in the system component. However, in a running system model, a process component represents the virtual address space and scheduled by the processor. Indeed, a thread component is the minimum schedulable unit under execution, and then, they are concepts that require detailed attention as they include the behavior of AADL. What's more, our goal is to verify system behavior, so in this section, we focus our experimentation on software components in the software model and thread management. Besides, the mode semantics is not yet completely stabilized in the standard so we take no account of mode management, and our work highlights several constructions(like Glob-al_Timer, Dispatcher, and Scheduler) to make the AADL system model running and also its semantics of components more coherent.
According to the AADL standard, the running model of software components can be described by execution automaton; the following paragraph describes that the software components are applied to the execution automaton and the management of communication (Figure 25).

Semantics of read Component Execution Model.
First of all, the necessary read execution model elements are currently specified according to the AADL running models by two points-dispatching and scheduling, and they both can be expressed by an automaton as shown in Figure 26.
Scientific Programming e dashed box represents read_Computation state,  Figure 26: read execution automaton. Scientific Programming code of state conditions management part in Isabelle/HOL is shown in Figure 27.
In the transitions automaton, the execution time, the elapsed time, and waiting time are controlled by the creation of the global clock and the various Deadline (ini-tialize_Deadline, compute_Deadline, recover_Deadline, etc.), and they provide the possibility to manage several kinds of read including periodical, aperiodic, and sporadic ones. In the case of execution Initialize, the code of temporal part in Isabelle/HOL is shown in Figure 28.
To support sending and receiving messages (data, event, and data_event) between components, the Connections provide the communication mechanism to manage messages from the source to the destination point. ey are typed with Access_Connections and Port_Connections. e Access_Connections type is used to model the data flow shared by access between components like Sub-program_Access and Data_Access, and the Port_Connections type is used to model transfer of data or events between ports. All types also include the Parameter_Connections, which models a data flow representing the parameter of subprogram included in a read, but this type is not managed in our transformation on account of the practical frequency. Now, we focus our presentation on the Port_Connection type. It deals with the processing of the sent and received messages and the properties describe several behavioral features (like the Queue_Size, Queue_Processing_Protocol, and some other properties) to define a queue of messages associated with a port. e processing of the messages received by read is carried out when it is in the execution state read_Computation. is state is reached after the dispatch of read. Unfortunately, these necessary concepts are not described explicitly in the AADL standard, so we should take into account an execution model definition.
In our work, several processing conditions are added on the read semantic to specify the Connection model. For example, the port queue state is estimated and the messages on the queue are handled by a dispatch mechanism. is mechanism is dedicated to detach the internal behavior of a read and the message consumption. In the read execution model, the dispatch action is performed on the transition between the state read_Suspend_Wai-ting_Dispatch and read_Computation. Generally, the message once arrives on the ports will be copied in variables in the Behavior of the read through the dispatch. In the execution state of read_Computation, the read handles its behavior with data and event copies. So, we combine the state of the Behavior and add the definitions "is_port_-queue_empty" and "handle_port" to specify and to conceptualize the Connections based on the AADL standard properties. In the case of execution Initialize, the code in Isabelle/HOL is presented in Figure 29. For these additions, they are mainly used at a design level for code generation and they also make the semantics of Behavior add into the model execution semantics to be a whole complete and continuous semantics.

Semantics of Process Component Execution Model.
A process represents a virtual address space at runtime, so the Process execution model is driven by the processor mainly and it works on the state to affect its own read execution model inside in effect. We consider that the Process execution model is managed by the clock and express its parent System execution state as an automaton as shown in Figure 30.
In the transitions automaton, the execution time, the elapsed time, and waiting time are controlled by the creation of the global clock and the various Deadline (load_Deadline, startup_Deadline, etc.), and also the prestate and poststate must be satisfied. In the case of execution Load, the code of the process execution Load part in Isabelle/HOL is shown in Figure 31.

Semantics of System Component Execution Model.
A system represents the runtime architecture of an actual system that consists of application software components and execution platform components, and it is the top hierarchy of the whole execution model, so the System execution model is only driven by the processor and it works on the state to affect its own Process and read execution model inside in effect. Same as the Process execution model, the system execution model is managed by the clock and it is presented as an automaton as shown in Figure 32.
In the case of execution Start_Complete, the code of the System execution Start_Complete part in Isabelle/HOL is shown in Figure 33.

Proof system Framework.
e calculation of the AADL execution model is actually a sequence of transitions. e computations set for whole executions with static information Σ is defined as Γ(Σ). We use function Γ(Σ, ρ, s, e) to present the computations of an execution system ρ starting up from an initial state s and execution e. A configuration of computation is defined as a triple δ � (θ, s, e) where θ is specified as transition rules in execution model systems, which have the form Σ⊢(θ n , s n , e n ) ⟶ (θ n+1 , s n+1 , e n+1 ).
A specification in the proof system is a tuple 〈pre, pst〉, where pre is short for the precondition, and pst stands for the postcondition. For each computation δ ∈ Γ(Σ, ρ, s, e), the configuration at index i is denoted by δ i , and we use θ δ i , s δ i and e δ i to signify the element inside δ i � (θ, s, e). We use A and C to denote assumption and commitment functions, respectively.

Invariant Verification.
e core of the correctness proof shows the invariance of states between components generated from it. e proof proceeds by induction on the former, and actually, it is long and contains many technicalities. In many cases, we would like to show that the AADL execution model preserves certain data invariants. Since the Behavior annex may not be a closed system; that is, a state may be changed by its environment or conditions. So that the reachable states of Behavior annex depend on both the initial states and the environment. A Behavior annex with static information Σ is defined as follows: e above formula demonstrates that it starts up from a set of initial states init, and it will preserve an invariant inv if its reachable states satisfy the predicate.
In this definition, δ denotes an arbitrary computation of ρ from a set of initial states inits and under an environment R. It requires that all states in δ satisfy the invariant invars.

20
Scientific Programming To show that invars is preserved by a system ρ, and it suffices to show the invariant verification theorem as follows.

Case Study: Formalization of an ARINC653-Based System
Our work aims at the formal specification and verification in a system development based on the AADL, so we apply the proof system for the specification, the validation, and the verification of an ARINC653-based System. In Figure 34, we provide an example, which is based on the ARINC653 OS platform using AADL with its Behavior Annex specification. is example is adapted from the ARINC653 annex document for the AADLv2 and shows a system with two partitions. It shows the components involved in the modeling of the ARINC653 system and illustrates the mapping of ARINC653 concepts to the AADL.
In fact, the architecture is described as the client thread "a_client" for calls and communication of action: either do not need to wait on the calculation of long distance calls and finished to send, or due to server for HSER subroutine call and waiting for the results to the values, send the results and return to continue to wait for the next execution among them, the thread a data port connection between tasks, each thread internal use behavior to define its specific behavior, describe the action to perform with state systems conditions and order.

Formal Transformation of AADL into Isabelle/HOL.
We define several modeling rules of model transformation from the AADL model into Isabelle/HOL specification for the next step about formal validation and verification. e model transformation rules of AADL are specified with a set of corresponding rules between AADL and Isabelle/HOL in a way to obtain a modular specification, and a part of the transformation rules is described as follows.

Transformation of Components and Connections.
Transform components and connections to datatypes in Isabelle/HOL. As depicted in Figure 35, we show the segmental transformation code for the example thread in Figure 34.

Formal Instantiation, Validation, and Verification in Isabelle/HOL.
is section introduces the next formal steps of the example model after transformation into Isabelle/ HOL as well as the validation and verification with its proof system. In this section, we use the instantiation of the AADL example to formally specify and verify the properties of the system model.

Instantiation.
e basic transformation rules have been listed in Section 6.1, and we can use it to abstract an example of AADL model (see Figure 34) in Isabelle/HOL. In the implementation of AADL in Isabelle/HOL, we use record to create the framework, where components of AADL are represented as parameters and assumptions of record. Records are the Isabelle/HOL's approach for dealing with parametric datatype. Every component of the same type inside the system model can be mapped and encapsulated into an instantiation by Isabelle/HOL specification, and the component type and implementation are instantiated. In the last stage of modeling, we can integrate datatype to type variable as parameter and get the concrete AADL model code in Isabelle/HOL. For instance, the instantiation of the process type is implemented by the mapping function as follows: primrec process-type-map: ExProcess (ExPort; ExDataaccess; 'Subpaccess; 'Parameter) process-type where pro-tp1: process-type-map partition1-process � partition1-process-type │ pro-tp2: process-type-map partition2-process � partition2-process-type

Validation.
e part of rules for grammar have been listed in Section 4.2, and we rewrite the validation rules as 47 definitions in Isabelle/HOL. After the formal description of rules, we reach the validation phase to check the grammar of the AADL model above. In our work, we use the validation rules code to check whether the model from the transformation satisfies a given property specified with temporal logic. Since the lemmas of validations are consistent with the integrating model, the proof obligations for the validation rule are proven immediately after unfolding the definitions of the precondition, postcondition, and relations. After applying the conditional and the grammar rules on the components, only the proof of the verification of each lemma body is left. Using these auxiliary lemmas, the postcondition is proven immediately by applying the properties over multisets. All the lemmas of validations are similarly proven, we omit the details here and the interested reader can refer to the Isabelle/HOL sources. We present an example of validation 7th as follows.

Safety Verification.
Safety represents "nothing bad will happen," which comprises reachability or properties expressed in the form of finite state automata by invariance.
After transforming the AADL abstract model to a target concrete model, we use the proof system (see Section 5.3) to verify its trace refinement and reachability properties.
Trace refinement checks "whether the abstract behavior trace of an implementation satisfies its abstract behavior trace of a specification." For instance, an assertion for trace refinement compares the whole abstract behaviors of a given action with another action, that is, whether there is a succeed relationship. For one of actions, the refinement analysis of actions is executed as follows.
Reachability refers to the ability to get from one state to another with one or multiple events. For instance, definition action-reach state shows the concrete state's reachability of the action for Behavior annex: Only with thread inputs and outputs without interior actions, the above definitions are used to verify whether all abstract behaviors refine the outside abstract behaviors, and whether the system reaches the goal of state.

Evaluation and Conclusion
Our work presents a method of the description of AADL and a methodology of model transformation from a comprehensive subset of AADL to Isabelle/HOL. To specify this transformation, a preliminary analysis and comprehension of AADL and Isar/Isabelle/HOL languages are necessary and reveal the need to take into account the various parts of the language: structural, execution model, and its semantics description. en, we use Isabelle/HOL as the specification, instantiation, validation, and verification system to conduct proofs against the properties of grammar and semantic in the structured proof language Isar, allowing for proof text naturally understandable for both humans and computers.

Evaluation
Results. All derivations of our proofs have passed through the Isabelle/HOL proof kernel. e total development of our framework has ≈ 1280 lines of Isabelle/ HOL specification and proof (LOSP). e concrete syntax of AADL consists of ≈ 630 LOSP, and the semantic of AADL consists of ≈ 650 LOSP. e two parts of specification and proof are completely reused in AADL . We use ≈ 750 LOSP to develop our validation system and ≈ 500 LOSP to develop the verification system including the formalization of 47 grammar rules. Finally, we develop ≈ 3300 LOSP for three case studies of AADL system model, which is ARINC653-based. We find two grammatical mistakes in the second case study and summarize that the instantiation in Isabelle/HOL has ≈ 3 times as much code as the lines of the AADL model.

Conclusion and Future
Works. Different from the majority of AADL formal approaches above, our proposition aim at defining a formal executable semantics of a comprehensive AADL subset to allow the instantiation, validation, and verification of behavioral and temporal properties. Besides, the considered AADL subset consists of both software and hardware AADL components with a significant set of temporal and queuing AADL properties. e considered subset covers fundamental features that can be used in more realistic applications rather than "without behavior" and "model transformation into other languages"  Scientific Programming approaches. Our experience is encouraging, but much more works remain ahead. First, increasingly larger AADL subsets should be considered to face complex applications such as shared variables by several threads with subprogram access, complex scheduling, etc. in the future works. Second, we need more complex industrial applications to examine our theory and the toolset, adjust our schema, and revise the technical architecture and implementation details, so as to realize our object that increase the confidence of safetycritical software. We plan to extend the AADL in Isabelle/ HOL to support more structures and stepwise refinement. ird, we need to verify more properties like the rules of model transformation conforms to semantics equivalence, the satisfaction of the noninfluence, etc. And the following important perspective concerns are compilation aspect from AADL to C language as our next step.

Data Availability
Data sharing is not applicable to this article as no datasets were generated or analyzed during the current study.

Conflicts of Interest
e authors declare no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.