Jorgen Hansson
email: hansson@sei.cmu.edu

Peter H Feiler

Aaron Greenhouse

Enforcement of Quality Attributes for Net-Centric Systems through Modeling and Validation with Architecture Description Languages

Keywords: Security, Modeling, Validation, AADL, Software Architecture

In this paper we discuss and demonstrate how to conduct validation of data quality attributes, e.g., security, data accuracy, data confidence, and temporal correctness, can be modeled and validated using an architecture description language such as AADL. We focus on security, specifically confidentiality.

Introduction

Net-centric system are intrinsically distributed system-of-systems comprised of a number of interconnected heterogeneous, geographically dispersed systems, where several systems are embedded and operate under real-time constraints. Sensor networks are increasingly being deployed in applications to monitor, collect, process, and communicate data obtained from the environment, and thus they provide data services to high-level applications. Data quality in a net-centric system can be compromised in a number of ways: confidentiality might be breached due to lack of adequate encryption or incorrectly assigned security clearance for subjects operating on object; confidence level of data might be insufficient in part due to the set size of active sensors or environmental conditions; the accuracy of sensor readings is also affected by environmental conditions; correctness of data is low as it is a function of its temporal coherence. Enforcing 100% accuracy, correctness, and confidence is in practice not always possible nor desirable as the cost becomes too significant with respect to cost, computational power, power consumption, quality of sensor etc. It is more desirable to ensure that data quality is within acceptable tolerance levels of the applications, not jeopardizing their correctness.

Model-driven engineering based on an architectural model is of paramount importance to validating the quality of data, and thereby ensuring that high-levelsystems are provided with data of sufficient quality and consistency driven by application requirements. Architectural description languages have success-fully been applied to prove system properties, often with a propensity toward task-or component-centric perspectives and, thus, generally preclusive of data quality attributes. We have developed a modelling framework using AADL for validating the enforcement of the previously mentioned data quality attributes prior to the implementation phases of the system. In this paper we present our developed methods for validating quality attributes, specifically security, using AADL. This includes The paper includes examples from modelling and validation of confidentiality under Bell-LaPadula-based frameworks [START_REF] Bell | Secure Computer Systems: Mathematical Foundations[END_REF][START_REF] Bell | Secure Computer Systems: Unified Exposition and MULTICs Interpretation[END_REF]. The approach supports other security frameworks, including Chinese Wall [START_REF] Brewer | The Chinese Wall Security Policy[END_REF][START_REF] Lin | Chinese Wall Security Policy-An Aggressive Model[END_REF], role-based access control [START_REF] Ferraiolo | Role-Based Access Control[END_REF], and information flow, [START_REF] Fenton | Memoryless Subsystems[END_REF][START_REF] Denning | A Lattice Model of Secure Information Flow[END_REF][START_REF] Denning | Certification of Programs for Secure Information Flow[END_REF].

Validation of Confidentiality

The concept of subjects and objects, where subjects operate on objects by permissible access operations (read, execute, append, write) enables us to model and validate security at both the software and hardware levels. At the software level we can view processes, threads, and software components as subjects and data objects are objects.

Determining the viability of a system given confidentiality requirements of data objects and security clearance by users, one can see the validation as a two-step process: (1) validation of the software architecture followed by (2) validation of the system architecture where the software architecture is mapped to hardware components. Validating the software requires us to • identify the data elements that we want to protect (objects); • determine their security requirements; • identify the components (software components, processes, threads) that should be allowed to access the objects; and • confirm the access is as specified by access operations.

Thus, we can ensure that data elements are accessed only by authorized users and that confidentiality (as given by security levels) and integrity (as given by access operations) are enforced.

By mapping the entities of a software architecture (e.g., processes, threads, and partitions) to a hardware architecture (consisting of, for example, CPUs, communication channels, and memory) and the like enables us further to ensure that the hardware architecture supports required security levels. Consider the scenario of two communicating processes, both requiring a high level of security as because the data objects requires secret clearance. Furthermore, the system platform in this scenario consists of a set of CPUs with hardware support for various algorithms that encrypt messages before network transmission. By modeling the system, we can represent and validate that processes and threads (now considered to be objects) can be executed (access mode) on CPUs (subjects) with adequate encryption support. Furthermore, we can validate that CPUs (objects) communicate data (access modes of writing and reading) over appropriately secured communication channels. In a similar fashion, we can enforce design philosophies saying that only processes of the same security level are allowed to co-exist within the same CPU or partition or that they can write to a secured memory.

In this section, we identify and outline desirable criteria to enforce when modeling and validating security using the model-based engineering approach. Our purpose in validating security is to ensure that • all components only access data they are classified for (through security level and compartments/categories) • data is only used on a need-to-know basis • modeling and validating security contributes to identifying identify possible errors • sanitization (i.e., lowering of security levels) of data is conducted controllably To model and validate the confidentiality of a system, we distinguish between general and application-dependent validation. General validation of confidentiality is the process of ensuring that a modeled system conforms to a set of common recommendations or design guidelines, expressed as a set of conditions that support system confidentiality independent of a specific reasoning framework for security. Those conditions should hold in the general case; as a result, they are necessary but not sufficient (i.e., satisfying the conditions indicates the system is viable for enforcing confidentiality). General validation of confidentiality assumes that subjects and objects are assigned a security level, such as ) , ( c cl that is the minimum representation to enforce what are commonly referred to as the basic confidentiality and need-toknow principles. Application-specific validation refers to validating the system given detailed confidentiality requirements and a specific reasoning-based security framework. For example, Bell-LaPadula-based models represent permitted access patterns between objects and subjects, against which operations are checked before they are allowed to be performed. These recommendations and design guidelines are conditions that verify an architecture is feasible (i.e., that the modeled architecture does not compromise security and confidentiality). Before elaborating on the conditions, we introduce a graphical notation (see Figure 1) and an example. -by a dashed arrow, and sanitization is only allowed to be performed on modified objects. Figure 2 depicts an example consisting of a number of scenarios, potential faults, and errors that we refer to when discussing the required and recommended conditions for performing general validation. For the purpose of simplicity and without loss of generality, we assume that the objects are data objects read (

Validating Subjects and Objects

Next we outline a number of conditions for validation.

Condition 1 (Basic confidentiality principle):

The basic confidentiality principle states that one should only be granted access if one has the appropriate security clearance, For example, if a document is classified as confidential, the viewer of the document should have confidential clearance or higher (i.e., secret or top-secret). We say that the basic confidentiality principle is enforced if, and only if, for all subjects and objects, the class (cl) of a subject equals or exceeds the class of an object on which it operates. In the example shown in Figure 2, this principle is true for all subjects. Thus, in order to validate the basic security principle, we only need to specify the security class cl for subjects and objects.

Condition 2 (Need-to-know principle):

The need-to-know principle states that one should only be granted access to a resource if there is a need. For example, a person having top-security document clearance should not necessarily be allowed access to all documents but only to those related to his or her function in a project. In our notation, the need is represented as a category c. We say that the principle is enforced if, and only if, the security level (cl,c) of each subject in the system dominates the level of the objects on which the subject operates. In the graphical notation given in Figure 2, adherence to this principle implies that the following relations must hold:

) , ( o , it actually has a higher security clearance than necessary for its purpose. We elaborate on this when discussing the principle of least privilege.

Condition 3 (Security level range checking):

The security level assigned to an object should be within the specified security levels of the object and the capacity of the subject. Some systems require that the security measures increase (e.g., when the systems appears to be under a security attack) in which case stronger encryption algorithms are deployed. Those algorithms require more computational power; in addition, the execution times of tasks processing data increase, and message sizes increase and require more network bandwidth. This increased resource demand adds to the end-to-end latency as well. For applications where power consumption is a major concern (e.g., sensor networks), it is important to maximize the lifetime of the network, which suggests that level of security is traded for operational lifetime. Furthermore, in overloaded systems part of the strategy to resolve an overload is to temporarily enforce the minimum acceptable security, decreasing the workload imposed on the system. Thus, adapting the security policy and the security levels to adequately match the current state and risk levels seems feasible. Indeed, one can adapt the security policy statically and dynamically. Assigning a security level to each subject based on the security requirements of the accessed objects, as we have previously discussed, is static as it implicitly states how a subject should operate to enforce the security given by an object (e.g., what encryption should be used). By assigning an allowed range of security levels for each object, we are explicitly expressing the minimum security requirements acceptable normal security level given normal operation maximum security level desired for certain situations or system states We model changing security levels in the following way. Each object i o can be given a range of security levels, expressed as

)] , ( ), , [( max min i i i i c cl c cl
. We refer to the security level desired in the normal system state as ) , (

i normal i c cl
.1 Recall, going back to a subject's security clearance, that a subject's security clearance represents its maximum security privilege, which also implies that it can manage and operate below this security classification. When 1 Note that only the level l changes; the category remains the same. Nothing prevents the categories from changing with the state, but we have not found an example where there is a practical need for it to do so. checking the ranges of objects, a subject j s needs to dominate the specified security classification range of each accessed object

i o -that is, ) , ( j j c cl should dominate ). , ( max i i c cl
Not dominating the range implies there are states when the subject is not authorized to access required object(s). The desired security level of an object, within its range, normally reflects the current system state. To facilitate adequate and meaningful checking when objects have security level ranges, one should connect each level with a system state to enable analysis for the different states. (In AADL, this connection can be accomplished by modes.)

Condition 4 (Principle of confidentiality constancy):

The principle of confidential constancy means that the security level of an object produced (access is write or append) by a subject as output should dominate the security level of all objects used as input (access is read or execute). The condition enforces the philosophy that the confidentiality of objects is maintained or increased. For example, a derived data object should be at least as confidential as the most confidential input data object since further analysis has been performed and more intelligence added; thus, its security level should dominate the security level of all input data objects. In the example given in Figure 1, this principle implies that the following relations should hold:

) , ( k k c cl should dominate ) , ( i i c cl .

Condition 5 (Controlled sanitization):

Controlled sanitization stipulates that lowering the security level of an object or subject should only be authorized and performed by a privileged subject. In Figure 2, Condition 5 is enforced in the following flows:

1 1 1 o s o → → , 4 3 3 2 2 1 1 o s o s o s o → → → → → → , 4 3 3 2 6 5 5 o s o s o s o → → → → → →
, and A subject using an object as input should not alter the security level of the object, even if the object is updated as an output from the subject. The rationale for this condition is that a subject can have a security clearance that exceeds the maximum required security level of an object. Increasing the security level of the object beyond its range implies that security requirements do not align between the subjects that operate on a dependent object. Thus, a subject with less security clearance than an object cannot continue its operation as expected. In Figure 2, consider the flow

1 1 1 o s o → → . If 1 s is increasing the security level of 1 o to (2,{a}), 5
s is no longer allowed to read 1 o , which probably was not intended in the general case.

Condition 7 (Hierarchical)

The hierarchical condition ensures that (i) a component has a security level that is the maximum of the security levels of its subcomponents, and (ii) all connections are checked to determine whether the source component of a connection declaration has a security level that is the same or lower than that of the destination component.

Consider the example given in Figure 3, which is an extract from the one shown in Figure 2 o , where security is not compromised). The principle of least privilege has been identified as important for meeting integrity objectives [START_REF] Mayfield | Integrity in Automated Information Systems[END_REF]; it requires that a user (subject) be given no more privilege than necessary to perform a job. This principle includes identifying what the subject's job requires and restricting the subject's ability by granting the minimum set of privileges required. With the object's security requirements specified in an AADL model, the least amount of privileges for the subjects can be generated in a straightforward manner by analyzing the security levels of all objects accessed by the subject. For a set of objects

Ο ={ 1 o , …, n o } accessed by i s , the least privileges ) , ( i i c cl of i s are given by         = = Ο ∈ Ο ∈ U j j l j i j l i c c cl cl
), ( max , the maximum security level clearance of accessed objects and required membership in the categories. Given that the subjects' privileges are specified, a mismatch between the least privilege and what has been specified results in two possible cases:

• The assigned privilege is insufficient. It does not dominate the required least privilege (i.e., the subject has been given incorrect privileges, the object has been wrongly associated with a subject, or there is an unauthorized access).

• The assigned privilege exceeds the minimum privilege, which either is unnecessary or a consequence of that the subject might be associated with other objects that have not yet been described in the model. In Figure 2, privileges of subject

Modeling and Representation in AADL

In the following, we describe our approach to mapping the concepts from the Bell-LaPadula security model to AADL 4.1 SECURITY LEVELS IN AADL The security level of a subject/object is usually a pair of a security class value and a set of categories. The classification value is drawn from a partially ordered set and denotes how securely an object must be handled and how privileged a subject is. Categories further refine the security level by labelling objects and giving subjects permission to access appropriately labelled objects. This style of security level captures the typical governmental model wherein data is labelled as unclassified, confidential, secret, or top secret and categories are used to further restrict access. Represented this way, a security level ( ) More specifically, the Classifications property type of the Class property is expected to be an enumeration. Because AADL treats enumeration literals as being ordered as they are declared in the enumeration type, the Classifications type thus provides a totally ordered set of classifications for the space of security levels. The property constant Default_Classification provides the default value for the Class property. The value of this constant is expected to be the first literal of the Classifications enumeration type. The Categories property type is also expected to be an enumeration. In this case, the enumeration is used to define the set of categories applicable to the problem space of the model. Because we are not interested in ordering the categories, we could have used aadlstring as the type instead. We chose to use a specific user-defined enumeration type because it provides better support for error checking; the AADL parser flags the use of categories that are not part of the declared enumeration type as syntax errors (i.e., typographical errors in category labels are detected at the time the model is parsed). Because aadlstring values cannot be checked this way, errors in category labels would be more difficult to detect (i.e., they would appear as unexpected security level mismatch errors The default classifications levels are the standard military classifications levels with the ordering unclassified < confidential < secret < top secret. The default categories are place holders to be replaced. As stated previously, the intent is that the modeler customizes the Classifications and Categories enumerations based on the domain of the system being modeled.

SUBJECTS AND OBJECTS IN AADL

In the Bell-LaPadula model, active subjects act on passive objects. In AADL, components communicate through ports and other categories of features. For the most part, data is not explicitly represented in the model; the exceptions are data subcomponents and data access features. Instead, data ports and other features are associated with a data classifier that describes the data objects that flow over connections and into or out of ports. A feature, with its associated attributes and properties, is a proxy for the data that pass through it. These observations motivate us to consider, in general, AADL components as subjects and AADL features as objects.

AADL Components

We treat all AADL components with the exception of data and subprogram components as subjects. Components are sites of activity that coordinate the movement and generation of data throughout the system. Each component is expected to have a security level to describe its clearance to utilize objects. Table 3 shows an example of a component type with a security level. AADL data components are pure objects. Although they can contain subprogram features, data components do not possess an active nature: external threads of control must invoke data component's subprograms. A data component is operated on through data access features that enable direct access to its contents. Thus, a data component is expected to have a security level to describe its contents. AADL subprogram components are both subjects and objects. They are subjects in the sense that they have the capacity to manipulate objects as a result of being executed. But they are objects in the sense that they need to be executed by an external agent. So a subprogram component is expected to have a security level to describe simultaneously its clearance to use objects and the clearance required to invoke the subprogram.

AADL Port Features

Because of its name, the data port feature is the most obvious starting point for the discussion. A data port feature transmits or receives a data object. It is thus clearly a conduit through which we can observe a component's access to a passive Bell-LaPadula object. A fully specified data port feature includes a data classifier that describes the data objects that pass through the port. When this classifier is available, we retrieve the Class and Category properties from it to determine the security level of the data port feature; when the classifier is not available, we retrieve the security attributes from the feature itself. This is consistent with the metaphor that the data classifier describes the data that passes through the port.

Table 4 shows the declaration of a data port feature output in the thread type producer. The security level of the feature is (confidential, {A}) because that is the security level of the data type A. Event data port features and subprogram parameter features are modeled in the same way as data port features. Event data port features differ from data ports only by their delivery semantics, so it is also straightforward to consider them as Bell-LaPadula objects. Because subprogram parameter features also represent the transfer of data objects, we consider them to be objects in the application of the Bell-LaPadula model. Event ports do not pass explicit data objects between components. The raising of an event, however, can be interpreted as the transfer of an "event happened" data object, one that need not be explicitly represented because there is only one value. Alternatively, one can easily imagine the need to constrain the observation of particular events to those components with an appropriate security level. For example, an event that communicates that an intruder was detected should not necessarily be publicly available because we might not want the intruder to be able to learn of the detection by querying a public access point. We thus also consider event ports to be objects in the Bell-LaPadula model. Because it never has an associated data classifier, an event port feature's security level property values are always retrieved from the feature itself. Table 4 also shows the declaration of an event port feature interrupt in the thread type producer. Its security level (confidential, {B}) must be explicitly declared with the feature. The security level of a port represents the exact security level of the data that passes through the port. In particular, it does not represent the maximum security level of the data. Such a choice would cause less precise modeling and analysis. We deliberately opted to provide more precise modeling and analysis by having a port's security level represent the exact security level of the data passing through the port. 4.2.3 AADL Port Group Features AADL port groups aggregate features. From an architectural point of view, they are a container for ports. A fully defined port group feature includes a reference to a port group type. The port group type declares the features of the port group. As with port features, the security level of the port group feature is obtained from the port group type declaration. As a basic principle of containment, we require that the security level of the port group dominates the security levels of the features in the port group. The feature declarations in the port group determine the security levels of the ports in the port group. 4.2.4 AADL Access Features Unlike data ports, data access features represent direct access to a data object that is ultimately represented by a data component instance. We must still, however, treat the feature as a proxy for the data because the exact data component being accessed is unknown outside the "providing" component. As might be expected, the rules for checking data access features differ from those for checking data port features due to their differing semantics in AADL. So Class and Category as defined previously, do not apply to data access features but to data components. If we were to modify their definitions with the access modifier, as shown in Table 5, however, the properties would apply to data access features but not data components. The solution is to declare a second a pair of property names that apply to data (and bus) access features only. This declaration, unfortunately, makes annotating the model more inconvenient, but the strict checking of property applicability by the AADL tool environments prevents the wrong pair of properties from being used for a particular model element. The additional property definitions are shown in Table 6. Besides their name and applies to clauses, they are defined identically to the Class and Category. Our use of the secondary property set Security_Types now comes into its own because it prevents the modeler from having to modify two pairs of property definitions when the classifications and categories applicable to a model need to be altered. Bus access features are analogous to data access features, as Table 6 shows.

ACCESS MODES IN AADL

The Bell-LaPadula model defines four access modes to describe a subject's effects on an object:

• Execute access does not permit the subject to observe or alter the contents of the object. • Read access permits a subject to observe, but not to alter, the contents of the object. • Append access permits a subject to alter, but not to observe, the contents of the object. • Write access permits a subject both to alter and observe the contents of the object. Given our mapping of objects to AADL features and data and subprogram components, we must derive access rights based on the AADL semantics for those features.

AADL Port Features

Data ports transmit and receive data objects by marshalling and un-marshalling, respectively, complete objects between threads through buffers that represent the port in the component. That is, objects obtained from an in data port are read, and objects sent throughout data ports are newly created. Thus, an in data port corresponds to read access, and an out data port corresponds to append access. An in out data port is bidirectional, but not on the same data object: it is more like a port that can be used for both sending and receiving object, but not simultaneously. When used to receive, an in out data port thus corresponds to read access, and when used to transmit it corresponds to append access. Event ports communicate events between threads. An in event port facilitates the observation of the event's occurrence and corresponds to read access. An out event port creates a new announcement of the event and corresponds to append access. Again, an in out event port is never simultaneously observing and announcing, so its access mode is determined according to its current usage. An event data port combines the semantics of an event port with that of a data port. For our purposes, an event data port is like a data port; in particular, event data ports transmit complete data objects between threads. Unlike an in data port, an in event data port queues received objects. You might suspect that an in event data port is considered to have a write access because it must read from and modify the queue. However, it is worth noting that the queue is not significant for security analysis, since we are interested in the data being transmitted through the queue. The semantics of subprogram parameter features are similar to those of data port features. Data is copied into the subprogram when it is called and out of the subprogram when it returns. As with data ports, an in parameter corresponds to read access, an out parameter corresponds to append access, and an in out parameter has read access during the call phase and append access during the return phase. 4.3.2 AADL Port Group Features Fundamentally, a port group is simply a bundle of ports, including those ports of any nested port groups. Conceptually, components interact via the ports contained in a port group not via the port group itself; the port group is simply an abstraction that bundles together related ports. Thus a port group itself has no direction, but the ports it contains do have direction. Therefore, in general, we cannot speak of the access mode of the port group feature, only of the access modes of the individual ports contained in the port group. These are determined as described in Section 4.3.1. There are, however, two aspects of AADL port groups that complicate the above reasoning:

• A port group might be empty. This aspect supports incremental modeling by allowing empty port groups to be declared to abstractly represent communication between components, even when the exact nature of the communication has not yet been decided upon. • Two port groups may be directly connected via port group connections. In fact, AADL allows access to the contained features of a port group when connecting a subcomponent and its containing component only; sibling subcomponents must connect port groups in their entirety using port group connections. There are cases where we must consider the port group as a single entity in terms of data access. In those instances, the security level of the accessed object is the security level of the port group. Just as the security level of a port group must be a maximization of the security levels of its constituent ports, so must the access attributed to the port group be a maximization of the access attributed to its ports. Conservatively, this implies that we treat a port group as having append access-the only choice when dealing with an empty port group (because we do not know the directions of the ports yet to be added). We can be less conservative by inspecting the directions of the port group's features: if all the features in a port group (including any nested port groups) are in ports, the port group can be treated as read access.

AADL Access Features

AADL data access features represent direct access to shared data. Although AADL distinguishes between provides and requires data access features, this distinction does not indicate the nature of the access to the data enabled by the port. The standard properties

Required_Access and Provided_Access apply to requires access and provides access features, respectively, and indicate the kind of access enabled by the feature. Acceptable property values are read_only, write_only, read_write, and by_method. The first three indicate direct manipulation of the shared data and map naturally to the access modes read, append, and write, respectively. The by_method access form indicates that the shared data object may be manipulated using the sub-program features associated with its data classifier only. Because we do not know what the sub-programs do to the data, we map by_method to the write access mode because it could read or write the data. Bus access features are analogous to data access features.

AADL Subprograms

The use of an AADL subprogram within a component implementation calls block corresponds to an invocation of the subprogram. For both subprogram features and subprogram classifiers, invocation corresponds to a Bell-LaPadula execute access. Even though the caller must be able to observe the sequence of machine instructions that compose the subprogram in order to invoke it, we do not consider invocation to be a read access because the subject is not reading the instructions themselves and using them as data for a computation. If that computation were performed-for example, to compute a checksum of the program's image in memory or as part of self-modifying code-we would have to consider the subprogram as data with the appropriate read/write/append access modes.

Conclusion

In this paper we have discussed how model-based engineering can support early modeling and validation of security. Specifically, using the AADL we have defined described common and welldefined security attributes and represented them in the AADL models. The adopted notion is primarily based on the Bell-LaPadula model, which has been recognized as a cornerstone in validating security. Using the AADL and based on the Bell-LaPadula and extended sibling models, one can model and validate security according to flow-based approaches, Bell-LaPadula, Chinese Wall, and rolebased access. To support security analysis, we have taken established criteria from the Bell-LaPadula model and defined additional criteria that allow us evaluate how viable a system is to enforce security, given confidentiality requirements of data objects and security clearance by users (e.g., ensure processes and threads are mapped to appropriate hardware, communicate over secured channels, and reside/store data in protected memory). The analysis techniques are implemented in an OSATE plug-in.

The overall objective of a secure system implies that security clearances are given conservatively (as opposed to generously). To this end, we can analyze models to derive the minimum security clearance on components in the model. Or to put it differently, we can use the notion of subjects and objects to determine the minimum security clearance for a subject based on the requirements of the objects being accessed by the specific subject. By also pointing out differences between actual security clearances and the minimum security clearance required, a system designer can evaluate how effective and tight security is. By providing mechanisms to ensure that sanitization is conducted within allowed boundaries, the designer is allowed to analyze and trace these relatively more threatening security risks, as since sanitizing actions are permitted exemptions of security criteria and rules, and as such should be minimized in the system.

Figure 1 Figure 1

 11 Figure 1: Graphical Notation of k j i o s o → → Figure 1 shows the general graphical notation we use for subjects and objects. The picture shows a subject j s accessing the objects i o and k o . j s has security level ) , ( j j c cl clearance, and the objects require that subjects operating on them meet the security classification requirements expressed as ) , ( i i c cl and ) , ( k k c cl . The relation

  → ) or written ( k j o s → ) by subjects; this notation simplifies the representation, since we know the allowed access operations from the example. The example in Figure 2 contains a feedback loop (

Figure 2 :

 2 Figure 2: Example with Object-Subject Dependencies

5 sdominates 3 o and 4

 534 does not dominate 1 o since 5 s does have membership in project {b}; thus, the example shows an incorrect access. Also, while 5 s

Figure 3 : Hierarchical Modeling Condition 8 (

 38 Figure 3: Hierarchical Modeling Condition 8 (Principle of least privilege)

5 s

 5 exceed the least privileges necessary given the current model.The least privileges of subjects represent a snapshot, since it is a function of currently existing objects in the model. This view may change over time as a model is incrementally refined (e.g., as additional objects and subjects are modeled and more detail added).

Table 1 :

 1 Because AADL does not support tuple-valued properties, we use a pair of properties to associate both a classification and a set of categories with each subject/object. The properties Class and Category that declare an item's classification and set of categories, respectively, are defined in the property set Security_Attributes, shown in Table1. The Property Set Security_Attributes Default_Classification that are defined in the secondary property set Security_Types. This facilitates customization of the space of security levels and is analogous to the AADL standard's use of the AADL_Project property set to allow customization of the property definitions in the otherwise fixed AADL_Properties property set.

					1 1 , categories class		is said to
	dominate another security level ( class	2 , categories	2	)
	iff	1 class ≥	class	2	and	1 categories ⊇	categories	2	.
	AADL properties associate security levels with the
	AADL components and features that represent
	subjects and objects. property set Security_Attributes is
	--Specifiy security class of a component.

Class: inherit Security_Types::Classifications => value(Security_Types::Default_Classification) applies to (data, subprogram, thread, thread group, process, memory, processor, bus,

Table 2 :

 2 ). Acceptable values for the Category property are actually lists of values of type Categories, thus providing the second component of the security level, the set of categories. The property types Classifications and The Property Set Security_Types

	Categories	and	the	property	constant
	Default_Classification are declared in the

Security_Types property set, shown in Table

2

.

Table 3 :

 3 A Thread Component with the Security level (confidential, {A}).

	thread producer
	// Features, etc. are elided
	properties
	Security_Attributes::Class =>
	confidential;
	Security_Attributes::Category => (A);
	end producer;

Table 4 :

 4 An Example Declaring the Security level of Features: Data port output gets its security level from the data classifier A.

	data A
	properties
	Security_Attributes::Class =>
	confidential;
	Security_Attributes::Category => (A);
	end A;

Table 5 :

 5 Modifying Feature Definitions

	property set Security_Attributes is
	Class:
	access inherit … applies to (data, …);
	Category:
	access inherit … applies to (data, …);
	end Security_Attributes;

Table 6 :

 6 The Property Set Security_Attributes, Revised to Handle Data Access Features AADL Subprograms as Features A subprogram feature represents an execution entry point provided by the component. The actual subprogram to which access is provided is described by the feature's associated subprogram classifier. As with port and access features, the security level of a subprogram feature is retrieved from the feature's associated subprogram classifier if it is present or from the feature itself if the classifier is missing.

	property set Security_Attributes is
	--Class & Category defined here...


Ulrich Eisemann

Model-Based Design for AUTOSAR Software Components

Keywords: AUTOSAR, Software Components, Code Generation

The AUTOSAR initiative is without doubt one of the most forward-looking and important developments in the automotive industry. Tool support is essential for efficient software development according to AUTOSAR, particularly for developing the actual application software in the form of AUTOSAR software components. This paper deals with the adaptation of model-based design and automatic production code generation techniques to the proposed AUTOSAR workflow. It shows that existing approaches are well suited for the development of AUTOSAR software, preserving all the advantages of model-based design such as early testability, precise specifications, and last but not least, automatic production code generation.

Introduction

For years now, the automotive industry has faced the problem of development times becoming shorter while the complexity of vehicle software grows. Modern development methods such as model-based design and automatic production code generation have become established as a result, see [START_REF] Beine | Transforming a Control Design Model into an Efficient Production Application[END_REF], [START_REF] Beine | Development of safety-critical software using automatic code generation[END_REF]. Alongside these activities, which are primarily oriented to the actual application part of the software, the AUTOSAR initiative aims to establish an open standard for entire electrics/electronics (E/E) architectures in vehicles, see [3]. The topic of this article is the adaptation of model-based design and automatic production code generation to efficient, AUTOSAR-compliant development of the application software itself, called AUTOSAR software components. A tool chain based on MATLAB / Simulink  /Stateflow  and TargetLink is taken as an example to demonstrate the concepts.

The AUTOSAR Software Architecture

According to the AUTOSAR standard, the software architecture of each AUTOSAR-compliant electronic control unit (ECU) has the general structure shown in Figure 1. The ECU software is basically subdivided into three different layers: the AUTOSAR software components, the Run-Time Environment (RTE), and the basic software. The AUTOSAR software components (SWCs) contain the application's actual functional code, while the basic software serves to abstract from the specific hardware, provides basic services for task management, hardware access, and communication drivers. The Run-Time Environment constitutes the "glue code" between the application software and the basic software, i.e., it provides well-defined, standardized interfaces for data exchange with the services of the basic software and between the AUTOSAR software components themselves. Data exchange is performed exclusively via the RTE, so not only is the application software completely abstracted from the hardware, it is also possible to distribute SWCs across different ECUs in a network independently of one another, without needing any modifications to the SWCs themselves. Thus, each SWC can be developed regardless of whether a second component is run on the same ECU or another. It is up to the RTE to make sure that communication is established between software components and basic software. Depending on the locations of the components, the RTE allows data exchange either directly via a shared memory or by sending messages via a bus. During software development, these differences are taken into account by what is called the RTE Generator, which generates the Run-Time Environment for each ECU appropriately. This approach means that AUTOSAR software components can be deployed fairly freely on different ECUs and different platforms. The reuse and replacement of individual components are also greatly simplified.

Model-Based Design for AUTOSAR Software Components

For designing AUTOSAR software components, a model-based approach using automatic production code generation is helpful. This ensures that AUTOSAR-compliant design benefits from the

Modeling

As a production code generator, TargetLink is fully integrated in Simulink/Stateflow and enables users to implement ECU functions designed as block and state diagrams directly as production-ready code.

For modeling AUTOSAR software components, TargetLink offers users special AUTOSAR blocks, see Figure 3, for specifying AUTOSAR structural elements such as runnable entities and ports. These special AUTOSAR blocks are now combined with the established TargetLink blockset used for modeling the algorithmic parts of the controller. From the modeling and code generation perspective, it makes little difference whether communication takes place between SWCs within the application layer or between an SWC and, for instance, services of the basic software. The latter have well-defined AUTOSAR interfaces just like software components, and communication is therefore specified in a similar way.

When modeling runnables, users can now combine the regular TargetLink blockset with the TargetLink AUTOSAR blocks. The algorithmic aspects of a runnable are modeled using the regular TargetLink blocks, and the partitioning of the algorithm into separate runnables and data exchange between them is modeled by adding TargetLink AUTOSAR blocks. Figure 4 shows the design of a simple controller for the AUTOSAR use case. Whenever a subsystem is to become an AUTOSAR runnable during code generation, the Runnable block must be dragged into it. For communication with other runnables, the Runnable Inports and Outports have to be inserted to receive and send input and output signals. This reflects the AUTOSAR principle that all communication between runnables is routed through an AUTOSAR interface, which is implemented in the form of an RTE macro during code generation. The algorithmic part of the controller, however, is modeled in the exactly same way as in the non-AUTOSAR use case.

Managing AUTOSAR-Related Data

Alongside the use of AUTOSAR blocks at model level, AUTOSAR-related information is kept in a data dictionary. This serves as a central data container and is used not only for AUTOSAR specifications but also for code generation information in general, such as data types, scalings and variables. These specifications define how individual signals appear in the generated code. The AUTOSAR-related information stored in the data dictionary are software components, runnables, ports, interfaces, etc. All these elements require a set of associated attributes which are defined by the AUTOSAR standard. Interfaces, for instance, must specify the data types of their enclosed data elements, while runnables must define the events by which they are activated.

To connect the AUTOSAR blocks on the model level with the AUTOSAR specifications in the data dictionary, the latter are simply referenced from the AUTOSAR blocks. Thereby, the appropriate AUTOSAR specifications are assigned to the individual signals in the model, see Figure 5, and the proper RTE macros are generated during code generation later on.

Figure 5: Specifying AUTOSAR properties in the data dictionary and referencing them in AUTOSAR block dialogs.

Production Code Generation

An essential advantage of model-based development is that the model serves as a reference, and executable code can be generated from it at any time, practically with just a click. This obviously also applies to AUTOSAR software components modeled with TargetLink. After all specifications have been made at block level or in the dSPACE Data Dictionary, actually generating AUTOSAR-compliant code is a matter of only a few clicks. The generated code is characterized, according to AUTOSAR requirements, in that all accesses to I/O, basic services, and communication with other components are implemented as RTE macros in the following way:

• Runnables become functions in the generated code.

• Incoming or outgoing signals -i.e., Runnable Inports and Outports -appear in the code as standardized RTE macros. Instead of referencing connected software components directly, which would make it impossible to reuse each component, these macros reference the components' own ports. In this sense ports are proxies for the components that will be connected to them later on. Figure 6 shows a small example: The "linearization_runnable" runnable reads one variable using the RTE macro Rte_Receive_RequiredSignals_pos and writes the result using the macro

Rte_IrvIWrite_PosLinearization_LinPos.

The definitions of these macros are generated later on during the RTE generation phase once software components have been mapped to individual ECUs. AUTOSAR standardizes the syntax of these macros.

• Communication between the runnables of one software component is handled specially using so-called interrunnable variables, as in the macro Rte_IrvIWrite_PosLinearization_LinPos.

Generating Software Component Descriptions

As indicated in Figure 2, an AUTOSAR software component consists not just of the C code itself but also a software component description. This is standardized by AUTOSAR and constitutes an XML file which contains a precise characterization of the structural elements contained in a component, such as runnable entities, ports, and communication interfaces. The component description provides the basis for a software architecture tool to read off the relevant properties of each software component, which enables the software architect to link the individual components in an AUTOSAR tool chain.

When model-based design and automatic production code generation are used, it is obviously not necessary to create and edit the software component description manually. Instead, all the relevant information is stored on the model level or in the data dictionary, and the description can be generated automatically at any time, for instance along with the AUTOSAR-compliant code. This ensures consistency between the model, code, and software component description. TargetLink supports the generation of AUTOSAR software component descriptions at a click, with the required information being retrieved from the dSPACE Data Dictionary, see Figure 7.

Simulating Software Components

One of the great advantages of model-based design has always been the ability to simulate functional behavior at very early stages of the development process. This paves the way for immediate validation and verification techniques and hence greatly reduces the risk involved in the development process. These advantages also hold true for the modeling of AUTOSAR SWCs.

For the purpose of simulation, the modeled AUTOSAR software components are included in a special simulation frame realized by a TargetLink subsystem, see Figure 8. This makes sure that software components can not only be simulated on the block diagram level, usually called model-in-theloop mode (MIL), but also in software-in-the-loop mode (SIL), in which the generated code is executed for the controller part of the model. The AUTOSAR standard specifies that runnables are activated by so-called RTE events. Simulink provides a comparable concept in the form of function-call-triggered subsystems, whose execution is actuated by events from other blocks. Consequently, runnables are implemented as function-call-triggered subsystems, see Figure 9. It is a common practice to activate function-call-triggered subsystems, i.e. the runnables, by events from a Stateflow chart residing outside the software component, see Figure 8. The latter is therefore used only for simulation purposes and has no bearing on subsequent code generation steps or the software component itself, see [START_REF]Applying Simulink to AUTOSAR[END_REF]. If a runnable is time-triggered, it can also be implemented as an ordinary Simulink subsystem with the proper sample rate.

For software-in-the-loop simulation, code for the AUTOSAR SWC is generated and wrapped in a Simulink S-function, a concept for including user code in a Simulink simulation. To build the Sfunction, wrapper code resembling a simple Run-Time Environment has to be generated along with the actual component's code. During software-in-theloop simulation, the blocks inside the TargetLink subsystem in Figure 8 are replaced by the generated S-function. The same concept can be used to perform what is known as processor-in-the-loop simulation (PIL), in which the code is executed on an evaluation board containing the target processor.

However, the capacity to realistically simulate AUTOSAR SWCs in Simulink, be it in MIL, SIL or PIL mode, is limited. Simulink simulations can serve to test the functional behavior, but they are not sufficient for proper simulation of real-time behavior, which arises, for instance, from later mapping of runnables to the tasks of an operating system.

Integration in an AUTOSAR Tool Chain

Production projects in the automotive industry nowadays often take individual software components as the starting point for development. After an AUTOSAR software component has been successfully developed, for instance with TargetLink, it has to be integrated in an overall AUTOSAR application. This procedure is of course supported by the AUTOSAR methodology and system design tools such as SystemDesk serve that purpose, see [START_REF] Stichling | From Function Design to System Design in Model-Based Software Development[END_REF]. A software integrator uses SystemDesk to integrate individual SWCs provided by function developers to make a system. The AUTOSAR SWC descriptions are imported into the tool, providing all the necessary information about the ports and interfaces of the required software components. Using model-based design on the system level, the integrator now simply connects individual components to model communication between AUTOSAR SWCs and the basic software, see Figure 10. Tool support is applied to check compatibility between the interfaces of software components. If the interfaces are not compatible, for example because different fixed-point scalings were used, the function developers have to adjust the interfaces.

Rather than starting from individual function models (bottom-up approach), it is to be expected that an architecture-driven procedure (top-down approach) will be pursued in the future. A software architect first designs the whole architecture in a system design tool and specifies the connections between SWCs and their formal interfaces at an early stage in the development process. Individual developers then transform functional models into AUTOSAR SWCs based on the specified software architecture. The advantages of this approach are that compatible interfaces are created systematically and that all the signals required are provided by other SWCs. In addition, each function developer can use the software component description to generate a frame model as a starting point to migrate existing function models to AUTOSAR more easily. To build the overall AUTOSAR application, it is of course necessary to perform an RTE generation step. As mentioned before, AUTOSAR-compatible application software must not use any direct calls to basic software layers such as I/O drivers, to other software components, or to the communication stack. Instead, standardized RTE macros in the components' code are used for that purpose. It is now up to the RTE generator to provide implementations for these macros according to the configuration of the overall system. Once the software components have been properly connected by the software architect/integrator, individual software components have been mapped to ECUs and runnables have been mapped to tasks, an RTE generator has the necessary information to provide the implementation of the RTE macros. Hence, platform-independent communication patterns used in software component code are implemented with the proper communication means such as CAN messages, inter-task messages, and global variables. The RTE generator also generates the required tasks for the real-time application. A system design tool like SystemDesk also supports OS and COM configurations as well as exporting this information to other tools like EB tresos, see [START_REF]EB Internet Homepage[END_REF], which then serve to generate the OS and the COM stack to build the final AUTOSAR application. The whole tool interaction is summarized in Figure 11.

Conclusion

The AUTOSAR initiative is likely to achieve a substantial increase in the efficiency and quality of automotive software development if the development process is supported by proper tools. As regards the actual application software, model-based development is the most obvious approach. The paper therefore shows how a tool chain based on Simulink/Stateflow and TargetLink can be adapted to model AUTOSAR software components on the basis of block and state diagrams. This enables users to design function models in their familiar development environment, with practically the same workflow and with intensive tool support. Most importantly, the software components can be directly implemented in the form of highly efficient AUTOSAR-compliant production code ready to be integrated on an AUTOSAR ECU.

The paper also highlights the importance of seamless integration of model-based design techniques in an AUTOSAR tool chain, especially their interaction with architecture tools and RTE generators. As a whole, the development of AUTOSAR software components benefits greatly from model-based design techniques, particularly since the success of AUTOSAR is heavily dependent on efficient tool support.

Figure 1 :

 1 Figure 1: The AUTOSAR software architecture with the layers AUTOSAR software components (SWCs), Run-Time Environment (RTE), and basic software.

Figure 2 :

 2 Figure 2: To adapt model-based design to AUTOSAR requirements, it is necessary to generate AUTOSAR-compliant code and software component descriptions in XML format from models.

Figure 3 :

 3 Figure 3: Library with special AUTOSAR blocks for modeling AUTOSAR SWCs.

Figure 4 :

 4 Figure 4: Designing a controller for the AUTOSAR use case by combining algorithmic blocks such as Gain, Switch, and Look-UpTable blocks with AUTOSAR blocks.

  void linearization_runnable(void) { /* storage class for local variables */ SInt16 S13_switch1 /* LSB: 2^-10 OFF: 0 */; S16_pos pos /* LSB: 2^-10 OFF: 0 */;

Figure 6 :

 6 Figure 6: Example code fragment for the simple controller in Figure 4.

Figure 7 :

 7 Figure 7: Excerpt from a software component description file, which can easily be generated along with the AUTOSAR compliant-code.

Figure 8 :

 8 Figure 8: Modeling style to properly simulate AUTOSAR software components. Runnables are included in the TargetLink controller subsystem and activated by events emitted by the Stateflow chart called Chart.

Figure 9 :

 9 Figure 9: Runnables are implemented as functioncall-triggered subsystems and activated by function calls emulating AUTOSAR RTE events.

Figure 10 :

 10 Figure 10: Using model-based design techniques for software architecture design.

Figure 11 :

 11 Figure 11: Interaction between functional behavior modeling, RTE generation, and OS and COM stack generation.


Timed Properties RAMS Constraints Abstract Architecture Proof Obligations Functional Architecture SW Architecture Assert Virtual Machine APP Containers

Keywords: MDE, TOPCASED, ECLIPSE, AADL, UML, profile, HRT-UML, OMEGA, LUSTRE, IF, RCM, DSL

The ASSERT (Automated proof based System and Software Engineering for Real-Time Applications) European Integrated Project (IST-FP6-004033, http://www.assert-project.net/) defined and experimented a multi formalism Model Driven Engineering (MDE) process, enforcing an approach with separated specification and refinement of functional and non-functional properties. • Functional specification, design and development is based on UML profiles to support AADL concepts [2] and behavioural specification. • Real time Architecture properties are based on extensions targeting Ravenscar Computing execution Model (RCM see [6]) constraints upon component interface and ports. • Model transformation is supporting correctness preserving rules towards a Virtual Machine execution environment or a verification dedicated environment. A tool chain called IDEA (Integrated Development Environment for ASSERT) supporting the process was developed by the CS ASSERT team on top of the Eclipse/TOPCASED environment allowing: • Integrated use of several formalisms in a development life-cycle (UML, AADL, IF[4]) . • Model transformation from UML to IF, AADL to RCM and RCM to Ada • Automated code generation

The approach experimented allows combined use of best suited formalisms and features for MDE developments. The TOPCASED tool proved to be a unique integrated toolset for prototyping UML and meta models supporting tools. The main feedback gained from applying the notations and approach on small to medium case studies is that UML profiling is not scalable, and that use of several Domain Specific Languages (DSL) seems far more suitable. Semantic clashes can be limited by raising the abstraction level, and by partitioning properties for verification.

Introduction

The main objective of ASSERT is to define a more reliable and scientific, proof based approach for system and software engineering based on modelling and model transformation, with preservation of system properties. The key idea is to minimize the validation effort for critical and complex real time systems by automating model transformation with smart combination of various pieces of proofs in the development life-cycle. Based on inputs available at the start of the project, (especially AADL [START_REF] Lewis | The SAE Architecture Analysis & Design Language (AADL)[END_REF] and various technology inputs from partners) work focused on the definition and implementation of an ASSERT MDE process [START_REF] Cass | A new Lifecycle for the Development of Aerospace systems[END_REF] based on:

• System Family approach: to benefit from already proven building blocks and frameworks; • Reuse of "functional" building blocks;

• Separation of concerns: functional and nonfunctional properties are modelled in separated spaces in order to ease a proof-by-construction concept within relevant scopes and domains • Combined use of appropriate formalisms and languages to capture the various properties

Based on requirement analysis, the SW architecture of a computer based system (CBS) is modelled at different levels of abstraction (see figure 1):

. SW & System Engineering Activities

• Functional architecture As the main scope of ASSERT is the space domain, a functional unit is responsible for a specific activity of the spacecraft (propulsion, thermal control, Guidance Navigation Control (GNC), communication…), and is mostly composed of equipment (gyroscope, star-tracker, thrusters…) and a software unit (SWU). SWU can be decomposed in several SW functional processes. Generic functional architecture may be defined with domain specific units such as mission management, Fault Detection Isolation and Recovery (FDIR) and a Telemetry / Telecommand (TMTC) unit communicating with all the others functional units • Physical architecture takes into account non functional properties (e.g. fault tolerance implying replicas; reactivity implying CPU availability and distribution on several processors, etc…). Others constraints have to be taken into accounts for e.g. power constraints, location constraints (accessibility for maintenance, etc…) • Real time software architecture is the definition of SW tasks, interactions and RT constraints taking into account previous constraints (functional and non functional requirements, choice of functional and hardware architecture). SW schedulable entities (SWSE) are defined as well with relevant mappings on SWU and processors.

Non Functional Engineering will complement functional architecture specifications through a set of non functional properties -mainly timed and RAMS (Reliability, Availability, Maintainability, and Safety) properties.

• Timed properties can be reactivity (defined between 2 events in the system) or deadlines resulting from activation of SW processes. • RAMS properties define fault tolerance properties, such as maximal tolerated outage of the system based on analysis of functional units and relationships. Altarica safety modelling[17],

[18] is used with an AADL to Altarica model transformation.

In that context, modelling activities and supporting formalisms had to be carefully engineered in order to eventually integrate within a process leading to automatic code generation of software applications, and compliant with the ASSERT target Virtual Machine abstracting the target execution platforms.

2

The MDE Approach

The ASSERT process promotes separation of functional specification of properties from non functional ones. Such an approach can be supported by a multi view MDE approach with each view focusing on dedicated domain abstractions and • a HRT-UML2 track relying on the HRT-UML2 meta-model that implements RCM [START_REF] Bordin | Correctness by Construction for High-Integrity Real-Time Systems: a Metamodel-driven Approach[END_REF]. These two tracks can converge at some specific points and a user can possibly switch from one to the other using the 3ADL-AADL and AADL-RCM transformation gateways.

Implementation

In the following we describe in more specifically the work performed by the CS ASSERT team to define the 3ADL/profile, model transformations and integration into the TOPCASED/ECLIPSE environment.

UML profiling

A profile is the standard way to extend the UML language. A UML profile can be integrated into any UML2 supporting tool (TOPCASED, Papyrus, RSM, Rhapsody...).

• A profile is defined as a set of stereotypes (a classifier that can be applied on an element). which can contain attributes (or tagged values) that are typed. • A profile can also contain types (base types, enumerations or even classes -not well supported by currently available tools-) that will be used for tagged values.

At the start of the project, as no graphical tool was available to support AADL, the first activity was to define and implement an UML2 profile supporting the AADL concepts. After defining the mapping of AADL concepts into UML ones, the implementation had to start first using the Rational Software Modeller from IBM-SW (RSM) tool (because of poor support for profile in early release of TOPCASED).

As AADL extensions was named 3ADL (for ASSERT AADL), the UML profile for 3ADL was named 3ADL/UML The latter was then constantly updated as new inputs were ready for integration, and ported to the TOPCASED platform, as soon as the OSATE tool from the Software Engineering Institute (SEI) was integrated in the TOPCASED distribution.

The profiling process consists in identifying and describing in a suitable way the subset of AADL concepts to which the actual profile is bounded, and then defining a convenient method for mapping them into UML equivalents with respect to the semantics. AADL concepts supported are:

• Packages, components, subcomponents, ports & port groups, subprograms & subprograms calls • Data/bus access • Connections • Binding • Properties Almost all AADL items could be mapped in a rather intuitive way to equivalent UML elements. The port group however had no equivalent concept in UML. Bindings had to be mapped into UML deployment relationships and property sets to packages of the 3ADL/UML profile. The profile is fully described in [START_REF] Boisieau | CS 3ADL/ASSERT AADL: Reconciling the Needs of Architectural Description with UML[END_REF]. All associated stereotypes are prefixed with "AADL"

The FW Profile [START_REF] Cechticky | A UML Profile for Designing Reusable and Verifiable Software Components for On-Board Applications[END_REF] defines rules that constrain the way UML2 class diagrams and state machines are built in order to enforce a framework approach [START_REF] Cechticky | A UML Profile for Designing Reusable and Verifiable Software Components for On-Board Applications[END_REF] The description of the FW Profile is best given in terms of 3 features:

• the restriction of the UML2 state machine model; • the component extension mechanism;

• the action language to define actions in the state machines. Integration of the FW profile was straight forward:

• extension scope is limited to state machines.

• the "FwtriggerOperation" stereotype for operation was compatible with existing elements in the 3ADL/UML. The FW stereotypes are prefixed with "FW" Integration of data modelling support. After analysis of impacts and potential extensions needed for data modelling in the ASSERT process, it appeared that relevant attributes could be directly supported by AADL properties and that no specific extensions were needed. The data modelling is based on the formal and standardised ASN.1 language [START_REF]Abstract Syntax Notation One (ASN.1) Specification of Basic Notation ITU-T Rec. X[END_REF] and existing support tools (editors and code generators). The principles are as follows (see figure 3):

• data types are specified, and refined using ASN.

3ADL/UML to AADL transformation

As AADL and UML meta-models are defined in the same formalism (MOF), 3ADL/UML models could be easily converted into AADL models by applying transformation rules on their meta-models.

The transformation was developed by TNI-Software using the ADT [START_REF] Allilaire | Adt: Eclipse development tools for atl[END_REF] plug-in of TOPCASED, a Java implementation of the Atlas Transformation Language (ATL) within the Eclipse Generative Model Framework project.

Atlas is a hybrid language (a mix of declarative and imperative constructions) designed to express model transformations as required by the MDA™ (http://www.omg.org/mda/) approach of OMG. It is described by an abstract syntax (a MOF metamodel), a textual concrete syntax and an additional graphical notation allowing modellers to represent partial views of transformation models.

A transformation model in ATL is expressed as a set of transformation rules. Despite issues in accessing stereotypes and a tricky user interface (in case of error) this transformation could eventually be successfully integrated in the TOPCASED environment. This 3ADL-AADL transformation was completed recently by the AADL-RCM one.

3ADL/UML to IF transformation.

To perform a transformation using ATL [START_REF] Farail | The TOPCASED project: a Toolkit in Open source for Critical Aeronautic SystEms Design[END_REF] both the source UML meta model and the target IF meta model are needed. If the UML meta model was at hand in the EMF technology (from ECLIPSE), an IF meta model had to be designed.

The IF meta-model was derived from the IF language grammar [START_REF] Bozga | IF toobox for validation of timed asynchronous systems[END_REF], and produced in several iterations to take into accounts intermediate attributes related to the transformation steps.

It appeared soon that a stepped process too would be needed to support parsing of OMAL action language. Whereas the initial choice of ASSERT contributors was to rely on the ECLIPSE development environment as the common integration platform, the motivation to shift to TOPCASED was to benefit from the added value brought over ECLIPSE:

• early availability of graphical editors for AADL

• meta model management tools and relevant services (editor generator, model comparison) • communication support with external tools through the external bus (through a SOAP server and adapters) On the down side we had to suffer from an immature implementation. All UML2 diagrams were not supported, stereotypes were not supported with early ATL, etc, what required experts of the environment close to developers (-fortunately it was the case at CS). However implementation matured considerably with TOPCASED 1.0.0 release In order to support deployment attributes capture, a small graphical editor called DAME (Deployment Attributes Model Editor) was developed using successfully the TOPCASED editor generator from a DAM meta model extracted from the RCM model.

Although not used in the tool chain, it provided interesting insights in the issues of handling meta models through sub meta models and consistency links.

3ADL2IF

In order to support the user in editing models and attributes using 3ADL/UML models, some add-ons were also developed: In summary, the TOPCASED tool proved to be a unique integrated toolset for prototyping UML, meta models, and model transformations. IDEA thus supports the use of several formalisms (or Domain Specific languages -DSLs), and automates the transitions between the modelling spaces.

Conclusion

This models to define a structured world, possibly projectable (or projected) to one or several formal spaces by correctness preserving model transformation. Such an approach is described in [START_REF] Bordin | Correctness by Construction for High-Integrity Real-Time Systems: a Metamodel-driven Approach[END_REF] and implemented in ASSERT through the "RCM" meta model. AADL is far more focused than UML and is easily mastered when compared to UML. AADL formalism is well suited for architecture specification as it supports formal definition of links between the software components and their execution support, as well as identification a how functions are implemented and executed. It thus supports capture of system attributes and properties and detection of mapping errors and analyses. With extension under work (see [15], [16]) and more supporting tool available, AADL could be the core architecture meta model to support the MDE approach. However AADL is not suited for functional specification and link with functional models(UML, LUSTRE/SCADE...) would require meta model integration work, and further development of transformation to more restricted formal languages and spaces.

Formal languages are complex to manipulate for SW designers, and direct monolithic modelling seems not possible on industrial scale. UML and AADL are suitable complementary formalisms for the modelling and capture of system components properties, but their lack of formal semantics render them unsuitable for verification. This drawback can be partially solved by transforming their models into formal ones such as IF or Altarica. It was demonstrated how to go that way, and round trip engineering support should be next. In addition solutions and support for correctness verification of model transformation software must be available before this technology can to be used for certifiable systems.

One of the goal of CS R&D activities is now to achieve better integration of formal verification techniques within industrial engineering contexts. An approach which is now going to be further evaluated is based on the concept of proof units [START_REF] Dhaussy | Mise en oeuvre d'unités de preuves pour la verification formelle de modèles[END_REF], a kind of projection by model transformation of user models into consistent "proof contexts" with all data and properties required for the verification.

Figure

  Figure 5. UML to IF code transformation steps

Figure 6 .

 6 Figure 6. IF meta model extract for behavioural description support The resulting 3ADL/UML2 IF gateway was experimented on two case studies provided by ASTRIUM-ST: • the ARIANE5 flight software (validation of the gateway through comparison of IF compilation results with the ones in OMEGA/UML1.4 [9]) • the Proximity Flight Safety System from ATV, a case study worked out by ASTRIUM-ST in to verify properties with Observers and IF simulation.

Figure 7 Figure 7 .

 77 Figure 7 presents the targeted tool chain as a set of plug-ins, built either on top of TOPCASED or Eclipse. All plug-in work on model stored in the EMF/Ecore format. External tools can communicate through AADL text files, and can be integrated through the external bus.• STOOD5 from Ellidiss[15] was the first tool integrated (http://www.ellidiss.com/) • ASN.1 toolkit is available from SEMANTIX (http://www.semantix.gr/) • OCARINA is available from ENST (http://ocarina.enst.fr/) and is going to be integrated in TOPCASED • 3ADL/SCADE gateway is available from Esterel -Technologies (http://www.estereltechnologies.com/products/scade-suite/) • 3ADL/ISG is available from BSSE (http://www.bsse.biz/)

ECore

Figure 8 .Figure 8

 88 Figure 8. Model Transformations implemented to support the ASSERT process Figure 8 summarises the set of model transformations actually implemented. IDEA is supporting: • Integrated use of several formalisms in a development life-cycle (UML, AADL, IF) • Integrated use of the HRT-UML tool implementing the RCM meta model. • Model transformation from UML2 to IF, AADL to RCM and RCM to Ada • Automated code generation based on MOFscript technology.

The deployment view supports capturing the

	properties.(see figure 2 below) • The functional view supports identification of
	SW "Application level" blocks and interfaces,
	using classical SW engineering principles,
	enhanced with new domain specific techniques
	(cf ETH SW framework and FW/UML profile[7])
	optimized for reuse and tailoring.. • The interface view defines logical containers
	encapsulating functional Application SW blocks
	as APplication Level container (APLC) defining
	component through provided and required
	interfaces By specifying RCM properties at the
	provided interface level, it is possible to perform
	property preserving generation of a real time
	architecture (concurrency view) through vertical
	transformation • The concurrency view or Virtual Machine Level
	Container (VMLC) view are run-time containers
	that manage tasks, synchronizations and
	transparent distribution. VMLCs are automatically
	generated from properly specified interface view
	and defines the schedulable real time
	concurrency architecture.
	The functional view and the interface view
	together constitute the Platform Independent
	Model (PIM) specification of the system in the
	MDE terminology, whereas the concurrent view
	does represent the Platform Specific Model
	(PSM) that in the current implementation targets
	the Ravenscar Computational Model (RCM) [6]
	The three views support distinct and non
	overlapping properties of the system, with
	consistency ensured by one meta model, and
	rules defining what semantics to attach (and how)
	to what model element. • physical architecture in terms of nodes,
	communication links, processor and allocation of
	APLCs to partitions, Virtual Machine (VM) and
	processors.
	Figure 2. ASSERT Multi-View Approach

Concurency view Feasibility analysis Hardware and deployment View (physical properties) Functional view Complete system

	VM Level Containers
	(RunTime Component)

Interface view (NF properties)

	Suitable formalisms for specifying and refining views
	were based on AADL and UML, possibly extended to
	support specific domain attributes:
	• for the functional component specification and
	view use of UML2 extended through the ASSERT
	AADL or 3ADL/UML profile[8] integrating:
	o	AADL concepts and properties[1]
	o	FW/UML2 profile to support FrameWork
		modelling as defined in [7].
	o	OMEGA/UML as defined in [9] and adapted
		to 3ADL/UML2
	• for the interface and concurrency views, use of
	an UML like formalism implementing the RCM
	meta model outlined above, and supported by the
	HRT-UML2 tool implemented as an ECLIPSE
	plug-in by Intecs (http://www.intecs.it/).
	• for the Hardware and deployment view use of
	AADL only.
	Feedback from elaboration and experimentation of
	the approach has highlighted two possible tracks
	which have both been experimented in the scope of
	the ASSERT project: • a full AADL based track with some ASSERT
	AADL	specific	extensions	(using	AADL
	properties)
						Functional Modeling
						Application Components	(UML, AADL, SCADE, ASN1,…)
						Application Level Containers
						(NF properties)
						Vertical
						transformation
						Virtual Machine
						RTOS
						Automatic
						code generation

Acknowledgement

This work was performed in the context of the ASSERT project coordinated by ESA and partially funded by the European Commission The authors of this paper gratefully acknowledge the contribution of their team colleagues in the ASSERT and TOPCASED projects.

Supporting a Multi-formalism Model Driven Development Process with Model Transformation, a TOPCASED implementation

Xavier Dumas 1 , Tristan Faure 1 , Sébastien Gabel 1 , Julien Honoré 1 , Maurice Heitz