Amitabha Ghosh
email: amitabhg@usc.edu

Luis Pereira
email: luisrpereira@eaton.com

Ting Yan
email: tingyan@eaton.com

Hui Cao

Modeling Wireless Sensor Network Architectures using AADL

Keywords: Wireless sensor networks, AADL, architecture modeling, dependability

Recent technological advances have enhanced the possibilities of large-scale development and commercial deployment of diverse applications using wireless sensor networks. As this development effort expands, it becomes increasingly important to build tools and formal methodologies that ease large-scale deployments of such networks. In this paper, we advocate the use of an architecture description language called AADL to describe wireless sensor network architectures. We highlight the use of component-connector paradigm of AADL in designing robust, performance-critical, real-time sensor network applications incorporating relevant dependability metrics. By careful analysis and extraction of the common requirements, we describe a case study, that of a simple data collection application using sensor networks, as a proof of concept of the AADL modeling approach. Lastly, we propose several wireless sensor network specific extensions to AADL that will further enhance the richness of such models.

I. INTRODUCTION

Wireless sensor networks (WSN) have found diverse applications in several domains, such as, industrial plants and environmental conditions monitoring [START_REF] Lu | Applying Wireless Sensor Networks in Industrial Plant Energy Management Systems[END_REF], diagnosis of health of civil infrastructures [START_REF] Xu | A wireless sensor network For structural monitoring[END_REF], military and security surveillance [START_REF] Yan | Differentiated Surveillance for Sensor Networks[END_REF], healthcare [START_REF] Malan | CodeBlue: An Ad Hoc Sensor Network Infrastructure for Emergency Medical Care[END_REF], search and rescue operations, etc. These networks typically consist of hundreds to thousands of MEMS (Micro-electro mechanical system) enabled tiny wireless embedded devices that are severely resource constrained in terms of memory, energy, computation, and communication capabilities. In applications where reliability and dependability are of concern, these networks should be fault tolerant and robust in the face of occasional node failures and lossy wireless channels while guaranteeing application specific performance goals.

Traditionally, mainstream WSN research has focused toward specific problems, such as, designing energy efficient routing and medium access control protocols, finding optimal deployment strategies to guarantee coverage and connectivity, accurate node and network localization, micro-second level time synchronization protocols, etc. On the contrary, practitioners of WSN have stressed the importance of architectural analysis of systems [START_REF] Hill | System Architecture Directions for Networked Sensors[END_REF] prior to implementation and analyzing trade-offs in design parameters in order to achieve desired performance and dependability goals. This tuning of system architecture is an increasingly complex process, which has been managed by architectural description languages (ADL), such as MetaH [START_REF] Krueger | Fitting the Pieces Together: System/Software Analysis and Code Integration using MetaH[END_REF], AADL [START_REF] Feiler | The SAE Architecture Analysis and Design Language (AADL) Standard: A Basis for Model-Based Architecture-Driven Embedded Systems Engineering[END_REF], [START_REF] Gluch | Tutorial: Hands-On Experiences with the SAE Standard Architecture Analysis and Design Language in High Dependability Design[END_REF], ACME [START_REF] Garlan | ACME: An Architecture Description Interchange Language[END_REF], Rapide [START_REF] Luckham | Specification and Analysis of System Architecture Using Rapide[END_REF], Wright [START_REF] Allen | A Formal Basis for Architectural Connection[END_REF], etc. ADLs provide a formal way of representing the architecture in terms of software and hardware components, their interconnections, constraints, and configurations. They seek to increase the understandability and reusability of architectural designs. A necessary feature of an ADL is its support for multiple analysis approaches so that tradeoffs can be realized across different domains. It should also support incremental analysis during the development process and multiple levels of fidelity for system evaluation. This incremental aspect allows the architecture specification to be used throughout the life-cycle.

Our contributions in this paper are the following:

1) We advocate the use of an architecture description language called AADL [START_REF] Feiler | Embedded System Architecture Analysis Using SAE AADL[END_REF] (Architecture Analysis and Design Language) to model wireless sensor network architectures. As noted earlier, due to the applicability of sensor networks in diverse domains, we believe that such an architectural modeling approach will provide insights in developing reliable systems and help designers play with tunable parameters prior to deployment to best suit application specific needs. 2) We address the lack of tools and formal methodologies in designing networked sensor systems and illustrate how AADL can help in describing their architectures that are flexible to analysis prior to implementation. We also discuss appropriate error modeling using the AADL Error Model annex. 3) As a proof of concept of our proposed approach, we describe a case study, that of a sensor network data collection application, and analyze the following three dependability metrics: (a) end-to-end average packet success rate (PSR), (b) end-to-end average latency, and (c) system life time. As the implementation environment, we used OSATE [START_REF] Feiler | Open Source AADL Tool Environment (OSATE) Plug-in Development Series[END_REF] (Open Source AADL Toolset Environment) on the Eclipse platform to build the AADL model and performed Monte-Carlo simulations. 4) Lastly, we propose several extensions to AADL that are needed to model WSN systems more accurately.

The rest of the paper is organized as follows. In Section II, we discuss the advantages offered by architecture description languages in contrast with the limited flexibilities of existing tools and simulators that have been traditionally used in modeling. In Section III, we give an overview of AADL by describing its basic building blocks, their interactions, and language features that are relevant in WSN design. In Section IV, we discuss the factors influencing the architecture of a WSN and define a mapping between the AADL and sensor network components. Section V describes a specific data collection application, and Section VI proposes several extensions to the basic AADL that would provide wireless sensor network specific features. Finally, we conclude in Section VII.

II. BENEFITS OF ARCHITECTURE DESCRIPTION LANGUAGES IN CURRENT WSN DESIGN PRACTICES

Industrial wireless sensors systems have gained recent popularity due to advances in low cost deployments, efficient energy and spectrum management, and local processing capabilities. There are commercial solutions currently available [2], [START_REF]Crossbow[END_REF] and standardization efforts [15], [30] to commoditize this technology by end users. Still, there exist application spaces in which these mainstream efforts yield suboptimal results in terms of resource efficiency. In applications like energy management [START_REF] Lu | On the Application of Wireless Sensor Networks in Condition Monitoring and Energy Usage Evaluation for Electric Machines[END_REF], localized properties of WSN such as topology, information volumetric, energy sourcing, and work-flow processes are exploited to provide a tailored solution.

Unfortunately, most of the current design processes and tool sets, besides being affected by architectural informalities, have a strong bias toward addressing some of the WSN architectural concerns like scalability, reliability, and energy consumption while neglecting or oversimplifying others like commissioning, cost, upgradeability, deployment, and architectural refinement. Common tools that are traditionally used for modeling and simulation, such as MATLAB/Simulink [START_REF]Matlab[END_REF], ns2 [22], GlomoSim [11], xUML implementations (Rhapsody [25] and Rational Rose [START_REF]Rational Rose[END_REF]), and OPNET [23] provide partial answers to these concerns since they focus mostly on the functional, informational, and concurrent viewpoints of the architecture (service primitives, data/packets structures, reactive behavior, and interactions), while the deployment and operational aspects are simply out of scope. Table I shows our assessment in their expressiveness power to a particular architectural viewpoint following the Rozanski-Woods approach [26], and Table II shows our assessment on the their capabilities to support architectural perspectives relevant to WSN. Obviously, a determined and skilled person can improve these tools to cover more aspects, but our advocacy is to focus the efforts in domain specific problems rather that transform the tool to cover objectives better suited by an architecture description language. An ADL enables a domain-neutral approach that facilitates automated and interrelated analysis wherever possible, while architect-friendly viewpoints (e.g., functional, informational, concurrency, and deployment) can be generated from the description for understandability and stakeholders' discussions.

With the employment of an ADL to represent the complete architecture and the usage of mapping rules to transform it for each domain specific tool, it is possible to perform a more comprehensive architectural evaluation while leveraging the existing knowledge base embedded in such tools for detailed evaluation. Under this framework, designers can build multiple models of the same functional element (e.g., physical, MAC, network) of a system representing different levels of fidelities (e.g., closer to a specific hardware platform) depending on the kind of analysis to be performed while preserving the underlying architecture.

AADL is gaining support from the industry because of its standardization efforts and UML interoperability, while providing support for a subset of desired ADL features needed for WSN design. Since AADL has a textual form, the inclusion or removal of elements satisfying particular requirements can be managed and potentially traced to requirements managing tools, enabling analysis under different requirements and assumption sets. For functional and informational viewpoints, every component in AADL has a type specification representing its external interface. Multiple implementations, possibly differing in internal structure of their subcomponents and connections, can be defined for the same component type, thus, supporting multiple model variants of the same architecture. For deployment and concurrency viewpoints, AADL enables the ability to specify the runtime architecture of the embedded application as a set of communicating tasks that execute on one or more processors. Users can specify concurrent units of execution (threads), their rates, deadlines, worst case execution times, as well as the interactions between those tasks. Thus, AADL focuses on platform specific models and defines semantics that can be executed to assess target specific characteristics. Also, an AADL specification can be annotated with fault and error conditions on the component models when studying dependability analysis. For instance, to model the occasional failure of sensor nodes or the lossy wireless channel one can define an error state to represent the failure, an error event that caused the failure (such as, sensor hardware failure or presence of noise), and an error propagation that represents the effect of failure among interdependent components. These kinds of software and hardware reliability analysis are difficult to model with simulators as they are architecture dependent.

III. AADL: ARCHITECTURE ANALYSIS AND DESIGN LANGUAGE

AADL is an architecture description language that is derived from the experiences based on DARPA funded ADL projects, MetaH [START_REF] Binns | Domain Specific Software Architectures for Guidance, Navigation and Control[END_REF] in particular, developed by Honeywell. AADL is a textual and graphical language to provide a standard and sufficiently precise (machine-processable) way of describing and analyzing the software and hardware architectures of realtime, performance-critical, embedded systems. It can describe the structure of such systems as a set of interconnected software components that are mapped onto a set of execution platform components. AADL describes common functional interfaces, such as events and data flow, as well as performancecritical features related to timing, resource allocation, faulttolerance, etc. Using the notion of operational modes and mode transitions, AADL can also describe the dynamic behavior of a system. In the following, we give a brief overview of the essential features of AADL that are relevant in designing a (Describes the environment into which the system will be deployed, including the dependencies the system has on its runtime environment) (Describes how the system will be operated, administered, and supported when it is running in its production environment) (Describes the concurrency structure of the system, mapping functional elements to concurrency units to clearly identify the parts of the system that can execute concurrently, and shows how this is coordinated and controlled) WSN architecture. A detailed description of AADL and its usage can be found in [START_REF]Architecture Analysis and Design Language (AADL)[END_REF].

The basic building blocks of AADL are called components, which are connected together to build a complete system. AADL provides several mechanisms to exchange control information between components, including message passing, event passing, synchronized access to shared components, and remote procedure calls. A component abstracts a specific element of the system by defining its interfaces and contents. The language syntax is composed of keywords that represent basic components, connections, and behaviors. Keywords are often annotated with additional keywords that describe features, properties, refinements, and extensions to the basic components. Features are used to exchange control and data via connections with other components, and properties are expressions that represent attributes with possibly associated values and behaviors of the component. AADL components are named and have types that represent their externally visible interfaces. They support the object oriented paradigm of inheritance [START_REF] Booch | Object Oriented Development[END_REF], in the sense that they can extend other component types and refine the inherited features. The AADL standard defines three categories of components: (a) Software, (b) Platform, and (c) Composite. We briefly describe these components and their inter-relationships in the following (see Fig. 1 for their graphical representations).

A. Software Category

The software components of AADL are data, subprogram, thread, thread group, and process. They model source text, virtual address spaces, and units of concurrent execution.

1) Data: The data components model static data, which may be shared by multiple threads and processes by declaring appropriate access control tags. Concurrent access to shared data components is managed by a concurrency control protocol specified as a property.

2) Subprogram: The subprogram components model functions that are executed sequentially. They can be called from within threads and subprograms. 3) Thread and Thread Groups: The AADL thread components model units of concurrent execution that are managed by a scheduler. A thread can in turn contain subprogram and data components. The dynamic semantics of a thread are defined using hybrid automata. It includes different states, such as suspended, ready, and running; transition events between states, such as dispatch requests, faults, and runtime service calls; and constraints on time that a thread will spend in a given state under a given circumstance. A structural grouping of threads within a process comprises a thread group. A thread group may require and provide access to data components.

4) Process: A process models partitions in terms of protected address spaces. Access protection of these address spaces, to represent fault tolerance, is enforced at runtime using properties. The binary image produced by compiling and linking the source text must execute properly when loaded into this virtual address space. As processes do not represent units of concurrent execution, they must contain at least one thread. However, they can also contain thread groups, data components and can access or share data components among different threads.

B. Platform Category

The execution platform components of AADL are processor, memory, bus and device. They represent hardware or software that is capable of scheduling threads, enforcing virtual address space protection, storing source code and data, interfacing with an external environment and performing communication for system connections.

1) Processor: A processor component is an abstraction that can schedule and execute threads. Processors can contain memory and require access to buses and can support different scheduling protocols.

2) Memory: Memory components in AADL model randomly accessible storage devices such as RAM or ROM. They can contain nested memory components and require access to buses and can have properties such as the number and size of addressable storage locations.

3) Bus: AADL bus components model communication channels that can exchange control information and data between processors, memories, and devices. A bus is typically a hardware that supports specific communication protocols, possibly implemented through software. Logical connections between threads that are bound to different processors transmit their information across buses which provide the physical connection between processors. Buses can be directly connected to one another and might require access to other buses.

4) Device: AADL device components model physical devices such as sensors and actuators that interface with external environments. Devices are logically connected to application software components and physically connected to processors and may require access to buses.

C. Composite Category 1) System: AADL system components organize hierarchical compositions of software and execution platform components. It is generally used early in the modeling process as a generic component and can be made more specific when decisions are made about which components will be included in the system.

One of the ways AADL supports logical connections among these components is through the directional flow of data and control using ports. There are three types of ports: (a) data ports that represent connection points for transfer of state data (e.g., sensor measurements), (b) event ports that represent connection points for transfer of events, and (c) event-data ports that represent connection points that represent transfer of events along with data. AADL components can have different modes that represent alternative configurations of the component implementation, with only one mode being active at a time. The dynamic behavior of the system can be captured through mode transitions that changes the set of active components, their configurations and connections. An AADL specification can be used in a variety of ways during system development, e.g., for documentation during preliminary specification, for reliability and dependability analysis, and for building of efficient, robust, and consistent system architecture.

IV. SENSOR NETWORK ARCHITECTURE MODELING

The idea of modeling a sensor network using AADL is to build a system architecture that will help in analyzing the cross-cutting aspects of design and the effects of embodiments on system performance, especially in resource constrained devices. AADL supports modeling a system at various levels of abstractions allowing quantification of system behavior by focusing on various performance characteristics (e.g., endto-end latency, network lifetime). Since the requirements of a sensor network are application specific, trade-offs are often made among the design parameters in order to satisfy specific performance and dependability goals. For example, in a surveillance network where real-time data delivery is necessary, a typical trade-off is between network latency and probability of packet reception. In order to guarantee freshness and low latency, data should be transmitted at a higher rate, however, this increases the probability of packet drops. Therefore, a suitable tuning of transmission rate and acceptable network latency is required. In this paper, our main goal is to describe an AADL model of a sensor network that would support dependability analysis. To this end, we focus on the following three dependability metrics.

1) Packet Success Rate (PSR): It measures the average end-to-end packet reception rate for all the nodes in the network over a period of time. The output of this metric could be a statistical distribution, or its mean and variance. 2) Latency: It measures the average end-to-end packet delivery delay for all the nodes in the network over a period of time. Like PSR, the output could be a statistical distribution, or its mean and variance. 3) System Life Time: It is defined as the maximal expected time that a certain fraction of nodes (e.g., 80% of all nodes) can still communicate with the base station.

In practice, it can be measured by the percentage of disconnected nodes at a certain time. The three dependability metrics as defined above have a correspondence with the general computer system dependability attributes: PSR basically maps to reliability, while latency maps to availability, and system life time maps to both availability and maintainability. We do not consider the performance metric, throughput, in this work. Note that, these three metrics might weigh differently for different applications.

To model a wireless sensor network, our first task is to identify the functionalities and interdependencies among the different sensor network components, and then describe them using appropriate AADL abstractions that map best with respect to their functionalities. At a very high level, a wireless sensor network is composed of three elements: (a) sensing nodes, (b) wireless medium, and (c) set of protocols and algorithms running on each node. At the highest level we model a sensor network as the AADL composite component, system.

A. Sensing Node

A sensing node has four basic components, as shown in Fig. 2: (1) a sensing unit consisting of a sensor and an ADC, (2) a processing unit consisting of a micro-processor and memory, (3) a radio transceiver unit, and (4) a power unit. AADL provides the flexibility to model these components at different levels of abstractions; however, a system designer would choose the appropriate level based on the analysis that needs to be performed for the specific application. Thus, a sensing node could be modeled at a high level using the composite component called system along with its associated properties, or it could also be modeled at a finer level using its subcomponent-specific models, such as representing the sensor hardware and the analog to digital converter using devices. In general, any kind of hardware component whose internals are hidden from the end user and which interfaces with the external environment could be modeled as a device along with its associated properties. In a similar way, the sensor measurements could be modeled using data and the interface between a sensor and the environment as a bus using ports. The processing unit, which consists of a CPU and a small memory, could be modeled using the platform component called processor with relevant CPU and memory properties. Lastly, the transceiver unit that enables node-tonode communication and the power unit, usually a battery, could also be modeled using device with relevant properties, such as its voltage and energy content. However, in our case we adhere to the high level modeling of the sensing node and the overall sensor network as a system and define properties corresponding to their subcomponents. This level of modeling is appropriate and sufficient for the dependability case study that we present later. The details of the AADL model of the sensing node is shown in Fig. 3. The variable names are selfexplanatory and hence we do not explain them in details.

The model for the overall sensor network is a system that specifies several parameters, such as the data sets location, the sink node, and the number of simulations. In addition, to compare the performance for different configurations, we add "analysis" scenarios for different cases (or profiles), battery capacity, power consumption, channels, transmission power levels, and latency. Due to lack of space we do not show the AADL code here.

B. Modeling Errors

Mapping the WSN components to appropriate AADL components with respect to their functionalities and the level of analysis required is only part of the complete AADL specification. We also need to define failures and error conditions that the components might be subjected to and define a complete error model of the system that would lend itself to a variety of analysis methods. The AADL Error Model Annex [START_REF] Feiler | Error Modeling with AADL[END_REF] provides this flexibility. In this section, we describe the basic concept of how to define error models on components and overall error behavior of the system.

The AADL error model annex is basically a means to annotate the architecture specification by supporting failures and error behaviors of the components. The error behavior of a complete system emerges from the interactions between the individual component and connection error models. Therefore, the overall system error model is a composition of error models of its components, where the composition depends on the structure and properties of the architecture specification. Each component error model is a stochastic automaton and the rules for building the overall system error model by composing the individual error models depend on potential error propagations and error management behaviors.

property set NodeProp is node id: aadlinteger applies to (system); -Location Properties node x: aadlreal applies to (system); node y: aadlreal applies to (system);

-Hardware Components Properties node memory: aadlreal applies to (system); node cpu speed: aadlreal applies to (system); node type: aadlinteger applies to (system);

-Environments Properties op temperature: aadlreal applies to (system); dormant temperature: aadlreal applies to (system); humidity: aadlreal applies to (system); vibration level: aadlreal applies to (system);

-Operating Profiles Properties case ID: aadlinteger applies to (system); profile ID: aadlinteger applies to (system); node sensing freq: aadlreal applies to (system); node sensing range: aadlreal applies to (system);

-Battery Properties node battery energy: aadlreal applies to (system); power consumption: aadlreal applies to (system); duty cycle: aadlreal applies to (system); isBattery: aadlinteger applies to (system); -Node State node state: aadlinteger applies to (system); node time: aadlreal applies to (system); route time: aadlreal applies to (system); node update interval: aadlreal applies to (system); route update interval: aadlreal applies to (system); -Node Reliability Properties node Live Prob: aadlreal applies to (system); link quality: aadlreal applies to (system); node neighbors: aadlreal applies to (system); battery ok: aadlinteger applies to (system);

-Radio Properties and others node comm range: aadlreal applies to (system); channel no: aadlinteger applies to (system); tx Power: aadlinteger applies to (system); processing time: aadlreal applies to (system); transmission time: aadlreal applies to (system); ack time: aadlreal applies to (system); timeout time: aadlreal applies to (system); end NodeProp; An AADL error model consists of the following declarations: (a) Error States that identify the current error state the component or connection is currently in; (b) Error Events that specify the transitions as to how the error states change; (c) Error Propagation that defines how state transitions happen; and (d) Error State Transitions that are conditions triggering transitions, and propagations as a result of transitions. Once an error model is defined, it can be associated with one or more appropriate AADL hardware, software, and composite components or connections. In Fig. 5 we illustrate a sample error model and associate it with the CPU (modeled as a processor) of a sensing node.

The first code segment defines an error model type called dependent with two error states: (a) the initial state Error Free, and (b) the error state Failed. It assumes that the failure event Fail and the repair event Repair can occur according to a Poisson distributions with parameters λ and µ, respectively. The error model assumes that a failure event can influence the behavior of other components that depend on it. This is made visible through the error propagation clause FailVisible with a fixed probability p. In propagations are the consequences of out propagations from other components; hence they do not need Occurrence properties. We defined two primary transitions for this error model implementation applied to a CPU in the second code segment: (a) when the Fail event occurs the state changes from Error Free to Failed, and (b) when the Repair event occurs the state changes from Failed to Error Free. The two supplementary transitions defined on the error model implementation states that: (a) if a component is in Error Free state and receives a FailedVisible in propagation then it transitions to the Failed state, and (b) the component remains in the Failed state when propagating FailedVisible out propagation. Once the error model is defined, we associate it with the CPU of a node within the constructs " annex Error Model { ** " and " **} ", as shown in the last code snippet. The error state of the CPU will follow the transitions as defined in the error model in case a failure or a repair event has occurred.

V. CASE STUDY: A DATA COLLECTION APPLICATION

Reliable and efficient delivery of sensor data is a fundamental requirement of almost all WSN applications. In this section, we describe a data collection application that serves as a proof of concept of the advantages and flexibility that AADL provides in modeling a WSN architecture. The software architecture of our system is shown in Fig. 4(a). There are essentially five components: (a) a GUI that takes inputs corresponding to each of the WSN subcomponents, such as the environment, radio characteristics, deployment, and routing; (b) an AADL WSN model generation component that generates the AADL model from the GUI input; (c) a model instantiation component that instantiates an AADL object from the model and the data set; (d) a topology formation component; and (e) a time series data analysis component that analyzes the WSN system with respect to the three dependability metrics described earlier.

We used four kinds of data in our analysis: (a) MAUI hardware reliability and node failure data (Eaton proprietary The sensor network used for our analysis is shown in Fig. 4(b). There are eight nodes in the network, one of which is the base station. All the nodes are configured as full function devices (FFD). The network is configured in the Mesh mode (one of the three modes in ZigBee specification) and it uses AODV (Ad hoc On-Demand Distance Vector Routing) routing protocol to forward data to the base station. We perform Monte-Carlo simulation using the MAUI reliability data to simulate node aliveness. The process, as illustrated in the Fig. 6, comprises four basic steps: (a) get node aliveness data at a certain time from MAUI hardware data; (b) throw a dice based on the aliveness probability to decide whether a node is alive or dead, assuming node aliveness follows Bernoulli distribution; (c) once a node is found to be alive, its link quality is queried using several node properties, such as the transmission power level, time, and channel number; and finally (d) calculate endto-end reliability. In a similar way we also calculate end-to-end latency and system life time.

A. Packet Success Rate

We evaluate the dependency of packet success rate (PSR), measured as a percentage of the average number of packets delivered by all the nodes to the sink, with different parameters, such as temperature, channel id, and transmission power level. Fig. 7 shows that temperature has a major impact on PSR -at high temperatures the end-to-end reliability decreases substantially, and is observed to be as low as 50% at 85 F. Fig. 8 shows the variation of PSR over time when different channels are used to communicate. At higher channel numbers (higher frequencies) the 802.15.4 signals interfere more with other signals, such as 802.11, and hence have reduced PSR. Lastly, Fig. 9 shows that the PSR decreases as the transmission power is reduced from 0 dBm to -15 dBm. This is due to the fact that at lower power levels nodes can communicate over fewer hops, and thus the number of hops required to reach the sink increases, therefore, reducing the end-to-end PSR.

B. Average Latency

We evaluate the average end-to-end latency for all packets delivered to the sink node and plotted its variation with time for different channels in Fig. 10, and with different transmission power levels in Fig. 11. As before, we again observe that the latency increases at higher channel numbers due to increased interference and also at lower power levels due to increased number of hops to the sink.

C. System Life

Lastly, we evaluate system life time as the average percentage of disconnected nodes with time and for different channels. The corresponding graphs are shown in Fig. 12 and Fig. 13, respectively. We observe that at higher temperatures the number of disconnected nodes increases sharply.

VI. WIRELESS SENSOR NETWORK SPECIFIC AADL EXTENSIONS

Although, in general, AADL provides a very good set of syntactic and semantic elements to support the modeling, design, and analysis of real-time embedded systems, to model wireless sensor networks in particular, the language as described in the first AADL standard needs to be extended to include additional WSN specific features. In this section we describe several aspects of the needed extensions.

A. Multiplicity Support

In most realistic scenarios a typical WSN deployment has hundreds to thousands of nodes. A homogeneous WSN consists of nodes that are very similar in hardware and software configurations, whereas a heterogeneous WSN may contain multiple significantly different types of nodes in both software and hardware. Moreover, for heterogeneous WSN the nodes can be categorized into small number of groups with nodes in each group of very similar nature. For such systems it is cumbersome to specify the model for each node individually since many of them are of identical configurations. This multiplicity issue is a challenge in the original AADL standard (version 1). The proposed AADL version 2 standard to be rectified in 2008 defines the syntax and semantics for array, which we believe will be very useful for WSN modeling.

B. Location Support

Besides names or IDs, for nodes with similar hardware and software configurations, the most important difference among them is their physical locations. Locations have significant impact on wireless communications, and therefore, play a very important role in the run-time functionality of both the network and an individual node. Based on the concrete application scenarios, we need to provide flexible means for the user to specify the locations of the nodes with various granularities. In some scenarios, the users may know the exact location of each node, while in others, the users may only know the density of the node deployment. We propose the following means: (a) specifying each individual location in the AADL model; (b) importing the locations from a file, whose path and name are specified in the AADL model; and (c) applying a specific deployment topology to an area specified in the AADL model. The deployment topology can be a rectangular grid or based on a statistical distribution, and tools (e.g., OSATE plug-ins) need to be implemented to take the topology and related parameters to allocate the detailed locations of the nodes in the network.

C. Wireless Channels Support

Realistic modeling of wireless channels is one of the most challenging tasks in a sensor network design. It is well known that radio signal strength is affected by various environmental factors, such as noise, interference, multi-path, and shadowing effects, as a result of which links could be asymmetric and stochastic in nature. Nodes that are very close to each other usually have strong links with high packet reception rates (PRR), while nodes that are farther apart have weak links with low PRR. However, nodes that are at medium distance away from each other exhibit random link characteristics. This region, where the uncertainty in the quality of wireless links is highest, is known as the transitional region [START_REF] Zuniga | Analyzing the Transitional Region in Low Power Wireless Links[END_REF], and depending on the output power levels and multi-path effects it can extend a wide range. Accurate means of specification of such an unreliable communication medium is a very important factor in WSN design that does not exist in the AADL standard. Since the quality of wireless links vary so much, it is cumbersome to specify all of them explicitly in an AADL model. One approach to take the per-link performance into account for the WSN model is based on empirical measurements. We build an AADL-based tool to get link level performance from empirical measurements into further simulation and analysis through a file interface. However, in reality the empirical measurement results are not always available, especially in the design phase prior to network deployment. In this case, it is easier to specify a well-known wireless model with related parameters in the AADL model. Tools need to be built to read the wireless model, related parameters, and other information such as node locations, infer the per-link performance and apply it to the model.

VII. CONCLUSIONS

In this paper we have highlighted the benefits of architecture description languages over traditional modeling and simulation tools, and in particular, advocated the use of AADL in describing wireless sensor network architectures. We demonstrated through a case study that such an architecture driven approach provides great flexibility in tuning system parameters prior to implementation as per application specific requirements, in particular, with respect to three dependability metrics: packet success rate, latency, and system life time. We also proposed sensor network specific extensions to the basic AADL language that would allow modeling WSN architectures in a richer way. Reliability and dependability analysis of larger systems with detailed error modeling based on extensive reallife data and richer modeling of wireless links are part of our future work.

Fig. 1 .

 1 Fig. 1. AADL components and their graphical representations.

Fig. 2 .

 2 Fig. 2. Basic components of a sensor node.

Fig. 3 .

 3 Fig. 3. The AADL model of a sensing node.

Fig. 4 .

 4 Fig. 4. (a) The software architecture for AADL modeling. (b) The WSN under analysis: 8 nodes send data to the base station using AODV routing.

Fig. 5 .

 5 Fig. 5. Sample CPU error model definition

Fig. 7 .

 7 Fig. 7. Packet success rate with temperature.

Fig. 6 .

 6 Fig. 6. Sensor network configuration and dependability analysis methodology. Top-left: node aliveness probability from MUAI data; top-right: node 3 is dead and hence not taken into account; bottom-right: link qualities determined; bottom-left: AODV routing path calculated.

Fig. 8 .Fig. 9 .

 89 Fig. 8. Packet success rate for different channels with time

Fig. 10 .

 10 Fig. 10. Average end-to-end latency with time for different channels

Fig. 12 .Fig. 13 .

 1213 Fig. 12. Average percentage of disconnected nodes in the first ten years for different temperatures

TABLE I POWER

 I OF TOOL LANGUAGE EXPRESSIVENESS TO SUPPORT ARCHITECTURAL VIEWPOINTS.

	Tools	Functional	Informational	Viewpoints	Operational	Concurrency
					Deployment
		(Describes a system's	(Describes the way in
		runtime functional ele-	which the architecture
		ments and their respon-	stores,	manipulates,
		sibilities, interfaces, and	manages, and distributes
		primary interactions)	information)

TABLE II CAPABILITIES

 II OF TOOL SUPPORT ANALYSIS ALIGNED TO ARCHITECTURAL PERSPECTIVES.

	ns2	Limited	Limited	No	Very Limited	Yes
	Executable	Yes	Yes	Very Limited	Limited	Yes
	UML
	OPNET	Yes	Yes	Very Limited	Very Limited	Yes
	Matlab	Very Limited	Limited	No	No	Very Limited
	Simulink	Yes	Limited	Limited	Very Limited	Yes
	Tools	Evolution	Development	Perspective, Availabil-	Performance and Scal-	Security
				ity, and Resilience	ability
		(The ability of a sys-	(The ability of a	(The ability of a sys-	(The ability of a sys-	(The ability of a system
		tem to be flexible in	system to be designed,	tem to be fully or	tem to predictably exe-	to reliably control, moni-
		the face of the inevitable	built, deployed, and	partly operational as and	cute within its mandated	tor, and audit who can per-
		changes that all systems	operated within known	when required and to ef-	performance profile and	form what actions on these
		experience after deploy-	constraints related to	fectively handle failures	to handle increased pro-	resources and the ability
		ment, balanced against	people, budget, time,	that could affect system	cessing volumes)	to detect and recover from
		the costs of providing	and materials)	availability)		failures in security mecha-
		such flexibility)				nisms)
	ns2	Very Limited	No	Yes	Yes	Very Limited
	Executable	Very Limited	No	Yes	Limited	Very Limited
	UML
	OPNET	Very Limited	No	Yes	No	Very Limited
	Matlab	No	No	Limited	Limited	No
	Simulink	Very Limited	No	Yes	Yes	Very Limited

ACKNOWLEDGMENT

The authors would like to thank Prof. Bhaskar Krishnamachari of the Autonomous Networks Research Group at USC and the members of the Innovation Center at Eaton Corporation for their valuable inputs and support. The work described here is supported in part by DoE and NSF grants CNS-0627028 and CCF-0430061. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the DoE or NSF.


Jean-Marc Dressler

A Walk through EMS2010 Modular Software Development

Keywords: Modular architecture, MBD, MIL, SIL 1. Architecture

The development of internal combustion engines is driven by two forces: the need for increased performances and most important of all the regulation for emissions reduction. Thanks to electronic control, in recent years engines have known spectacular progression in those two areas, but also a spectacular increase in complexity, especially for software. With the current high level of complexity rigorous processes are not enough to guarantee the quality. This is why RENAULT has launched the EMS 2010 (Engine Management System) project to build the standardization of the software structure with the support of its suppliers, especially the support of SIEMENS VDO. This article presents the main specificities of EMS 2010 software development through two parts. The first part introduces the EMS 2010 software architecture, its principles and main notions, and ends with a comparison with AUTOSAR. The second part goes through the technical particularities of the different steps of EMS 2010 software development from the specification of a module to its integration into a complete software.

An applicative architecture

An embedded software architecture can roughly be divided in two parts:

• The applicative software which contains the control laws and strategies which support the system functionality and performances. • The basic software which main role is to manage the hardware resources of the ECU and to provide services (communication, memory management, scheduling) to the applicative part.

For an engine manufacturer applicative software is the strategic part to define and control, and this is why EMS 2010 focuses on the applicative software.

As shown by figure 1, the EMS 2010 architecture covers the applicative part (the darker boxes) and its interfaces with the basic software (the three boxes surrounding the applicative software). The basic software itself remains specific to the supplier of the ECU.

A modular architecture

The EMS 2010 architecture has three level of composition: the higher level is the function (this is the level visible on figure 1), functions are divided in sub-functions which are themselves composed of modules. The modules are the atomic elements of the architecture and a complete software can contain about 200 of them.

A module has a well defined functionality and interface. Also the division into modules aims at reducing dependencies. The benefits of such a modular architecture are well known: • Module level validation (reduces the complexity and cost of validation). • Improved evolution management (impact analysis, containment, validation).

Another important principle of EMS 2010 is the reusability at the source code level. EMS 2010 distinguishes two kinds of modules:

• Specific modules which are specific to a supplier platform. Examples of specific modules are the basic input/output (functions BI and BO) modules which make the interface between the supplier platform and the applicative software.

Functions organisation

In this section we will have a closer look at the software structure showed by figure 1. The layout of the figure is organized so that the left to right orientation shows the sense of the main data flow between the functions, starting with the BI and ending with the BO. The modules in IN and OU functions perform applicative signal filtering and formatting. In the remaining functions we distinguish the transversal functions LB, DG and CM from the non transversal functions which contain the control laws and strategies for the engine sub-systems. The role of transversal functions is to provide common services to other modules:

• The DG (diagnostic) function contains the diagnostic services (i.e. interaction with diagnostic tools) and the failure manager. Note that the failure manager does not handle the faults itself since dysfunctional behaviour is managed by the modules themselves, but it collects the fault reported by the modules for diagnostic and fault confirmation purposes.

• The CM (communication) function is composed of one module which handles the applicative strategies for bus/network communications. This module is also responsible for performing multiplexing / demultiplexing of network frames so that other applicative modules only see the signals and never the frames. • The LB (library) function essentially contains one reuse module which provides commonly used operations (filtering, timers, …) through an API.

The platform adaptation layer

In order to provide an EMS 2010 compliant platform, each integrator supplier must implement and configure the EMS 2010 platform adaptation layer above his own basic software platform.

NVMY COM BI / BO

Applicative software

Reprog

Tasks definition

Libs

Standard files

Project conf

Figure 2: The platform adaptation layer

The first role of the adaptation layer is to provide an interface between the basic and the applicative software. This interface is composed of the BI and BO modules, the COM interface (mainly used by the applicative CM function) and the NVMY (the non volatile memory manager) interface.

In addition to those interfaces the adaptation layer provides the following non reuse libraries: an arithmetic library for saturated operations (additions, multiplications …), an interpolation library, a bit operation library and a memory management library. Those libraries are non reuse because they are low level and can be optimized for a supplier platform, and as they are widely used their impact on performance is important. The adaptation layer also contains the interfaces for the following services: the NVM (Non volatile Memory) manager, the lower communication layer (only used by the applicative communication module).

Finally the adaptation layer also includes the ECU reprogramming functionality, several EMS 2010 source files mainly used for portability (type definition) and the tasks definition and the project (off-board) configuration which we will both see in more details in the section about module integration.

Modularity mechanisms

At the centre of the AUTOSAR architecture lies the RTE. The RTE is responsible for inter module communications, and to that purpose provides sender/receiver and client/server mechanisms. Connections between modules are made through the RTE configuration by associating the ports of the modules. Compared to the AUTOSAR mechanism EMS 2010 is much simpler because of its static architecture. Modules communicate through data signals (implemented as global variables) and events (implemented as function calls). As EMS 2010 scheduling policy is almost completely cooperative there is no need to protect the global variables. Also there no configuration is needed to "connect" the modules because this connection is done through the signal and event names which are unique. This static architecture has the advantage of reduced resource consumption compared to AUTOSAR more generic mechanisms. Finally the off-board configuration mechanism is completely specific to EMS 2010.

Fault Management

The purpose of the AUTOSAR DEM (Diagnostic Event Manager) is very close to the EMS 2010 failure manager. But contrary to AUTOSAR, the EMS 2010 architecture does not provide a generic fault handling mechanism like the FIM (Function Inhibition Manager) as it is the responsibility of each module to handle the faults. To manage coherency of fault management at the system level, EMS 2010 relies on tools to analyze the degraded modes activated by a fault confirmation.

EMS 2010 software development

In this part we will walk through the different steps of the development of EMS 2010 reuse modules.

Specification

The MBD approach EMS 2010 takes full advantage of the MBD (Model Based Design) approach. Indeed each module specification is composed of several Simulink® models (Simulink® is a modeling environment developed by The MathWorks). Each model is executable and so can be used for simulation or rapid prototyping. This means that the specification is very detailed and can be validated, sometimes directly on the vehicle. Each module is actually validated in a MIL (Model In the Loop) environment; the test cases used for this validation will be reused for the validation of the final module source code. Each model also has an associated textual documentation to facilitate its comprehension and a data dictionary which gives more details on the characteristic of the signals definition (units, resolution …).

Specification structure

The specification of a module is composed of the following items:

• Specification elements: the elements are equivalent to sub-modules, also each element correspond to a Simulink® model and its interface. One of the elements plays the specific role of module scheduler, this means that it defines the execution sequence of the different elements entry points. • The MID (Module Interface Description): this is a textual document which describes the interface of the module (data and event inputs/outputs) and its off-board configuration. The interface of the module is actually a subset of its elements interface, defining such an interface avoids to expose unnecessary elements to other modules.

Off-board configuration

The off-board configuration mechanism takes place at the module level. Specification elements are not themselves configurable but simply are present or not in a given configuration. A configuration is defined by a set of configuration constants which can take a limited number of values. For example the variable engine_type can take two values: diesel and gasoline. Figure 3 shows an example of module with two configurations: gasoline and diesel. Note that since the module interface is a subset of its element interface, the module interface depends on the configuration (actually this is only true for data inputs/outputs) Figure 3: Module off-board configuration

Module coding and validation

By coding we mean the transformation of the specification in optimized C source code. As explained earlier the main characteristic of a reuse module is its portability: a reuse module can be integrated to any platform which implements the EMS 2010 adaptation layer. To achieve this portability RENAULT in close partnership with SIEMENS VDO has elaborated a set of coding rules. The coding rules:

• Set constraints on the implementation (the code must be C ANSI, only EMS 2010 libraries can be used …). • Define the structure of the module source code.

• Define the different software mechanisms (memory allocation, off-board configuration …).

Code structure

One of the main principles of the coding rules is the 1 to 1 relationship with specification, and this is reflected in the code structure.

The file structure strictly enforces a file structure of the module which closely matches the specification. Each specification element is implemented by a set of 5 source files named after the element (one C file containing the program, another C file containing the definition for observable variables and calibrations, and three header files for public and private declarations). In addition to files related to elements, a module contains several other files among which the most important are:

• The export file: this header files contains the declaration of all the items which are exported by the module to other modules. This mainly includes the variables produced by the module, and the module entry points/functions.

• The import file: this file simply includes all the export files of the modules which produces items which are consumed by the target module. Actually this file implements statically the dependencies between the modules. • The configuration file: this file implements the off-board configuration logic of the module.

Module interface

Elt2 Elt1

Elt3

Elt4

Elt5 Elt6

Diesel conf

Gas. conf

All confs

Again the 1 to 1 relationship with the specification is verified as the 3 files described above directly derive from the MID. This relationship is also enforced at a lower level, with naming rules for main functions and all observable variables. It is interesting to note that all observable variables and calibration have the same name in the specification and in the code and that this name is also used by the calibration and diagnostic tools.

Off-board configuration

In the section about specification we have seen the off-board configuration mechanisms simply consist in defining a sub-set of "active" specification elements for each configuration. This mechanism is reproduced at the code level by using conditional compiling. Each source file of an element begins with the inclusion of the configuration file immediately followed by an #ifdef ELEMENT_NAME… #endif block which encompass all the rest of the file. If an element is not present in a given configuration, the configuration file will not define ELEMENT_NAME and thus after the pre processing the element files will be empty and the element will not be present in the final binary avoiding unnecessary waste of resources. Thanks to this mechanism, there is a single set of sources for all configuration of a module.

MIL/SIL validation

One part of the module validation is done in a SIL (Software In the Loop) environment. Thanks to a dedicated tool and to the 1 to 1 relationship between code and specification, the integration of the module source code in the SIL environment and the comparison between MILS and SIL results is greatly facilitated. The test cases and environment used for the SIL are exactly the same as in the MIL. The module source code is compiled as a Simulink® Sfunction to allow its integration in the SIL Simulink® model. All observable variables can be compared which allows a finer comparison than if only inputs and outputs where compared. It is up to the human tester to decide if the differences between MIL and SIL results are acceptable or not.

Integration

Once the reuse modules have been coded and validated they are put in an electronic shelf. Each engine software project picks the reuse modules its need for its engine technical definition. Before the integration the integrator supplier (i.e. the supplier which provides a complete ECU integrating the reuse modules) must have prepared its EMS 2010 platform adaptation layer (implementation of BI/BO modules, non reuse libraries …). As not all modules are available at the start of the project, the integration is done incrementally. For each integration step RENAULT provides to the supplier:

• The code and MID of the reuse modules to be integrated. • The specification of non reuse modules to be developed or updated. • The tasks definition specification which defines for each task (periodic tasks like 10ms or 20ms, and events like the engine top dead center event), all the modules entry points to be called and their execution order. Note that this tasks definition is build directly from the specification. • A stubbing specification for the modules which will be integrated in the future. • The project off-board configuration specification, i.e. the value of each configuration constant.

EMS 2010 methodology defines the following process for the integration of the reuse modules in the supplier platform:

• The first step is to configure the platform adaptation layer in order to receive the new or updated modules. This step includes the following operations:

o Update of the project configuration o Configuration of the NVMY with the NVM blocks from the new/updated modules.

o Update the tasks definition. • The second steps consist in compiling and linking the software with the new modules. • The remaining steps essentially consist of static and dynamic checks at module and application levels to verify that:

o The integration has been done correctly.

o Hardware resources consumption (CPU and memory) is still within the project targets.

o Timing are compatible with the real time execution of the software (actually the coding rules define the maximum execution time for a module entry point)

The final software consist of a binary and its associated A2L file (the A2L file contains all the information necessary to diagnostic and calibration tools).

Conclusion

The first goal of the EMS 2010 project is to improve the quality of the engines software through modularity and code reuse. To support this modular architecture approach many new mechanisms but also processes and tools have been developed.

As EMS 2010 has progressed separately from AUTOSAR, its architecture and mechanisms are quite different. Today RENAULT and SIEMENS VDO bring their experience acquired on EMS 2010 through their participation to AUTOSAR phase 2. Modularity and code reuse have also opened the way to a business model were the developer of the applicative software and the provider of the electronic system can be different suppliers. At this time EMS 2010 software is running on ECUs from three different suppliers and each supplier integrates several modules developed by another supplier.

Glossary

Figure 1 :

 1 Figure 1: EMS 2010 architecture

MBD:

  Model Based Design MIL: Model In the Loop SIL: Software In the Loop MID: Module Interface Description ECU: Electronic Control Unit

  that reuse modules are portable at the source code level. Most modules are reuse modules, which means that they are developed once and then reused on the different engine projects. Together modularity and reusability set the basis for a simpler and better validation and therefore an improved quality of the final software.

	1.3 Configuration mechanisms
	EMS 2010 provides two levels of configurations:
	• On-board configuration: this is the usual
	calibration mechanism. It is mostly used to fine
	tune the control laws and strategies and adapt
	them to a particular vehicle. This mechanism
	provides a great flexibility as calibrations can be
	changed on a running ECU.
	• Off-board configuration: this mechanism has
	been introduced to efficiently handle technical
	definition diversity. This configuration takes
	place at compile time and as such is much less
	flexible than calibration but it avoid wasting
	memory resources with unnecessary code.
	With off-board configuration a module can handle
	different technical definitions such as different
	sensor or actuator technologies, diesel/gasoline
	engines with a unique module version. Alternative
	solutions would have been either to use different
	versions of the same module or finer grained
	modules but it would have introduced more
	complexity in the version management. The off-
	board configuration mechanism will be detailed later
	on.

• Reuse modules which can be integrated in any platform with an EMS 2010 compliant interface (e.g. a reuse module can be common to diesel and gasoline engines). The EMS 2010 software design rules ensure


Thomas Brixel

Impact of an IMA software architecture on legacy avionic software

Keywords: avionic software, migration, integrated modular avionic, performance measurement

The paper discusses the performance and timing issues when migrating legacy avionics software to an Integrated Modular Avionic (IMA). The software in question is running on a mission computer equipped with several Motorola 68020 processors and two dual redundant databusses. A new hardware was introduced due to obsolescence problems. To reduce risk the legacy software should be migrated to the new hardware with possibly no changes. Therefore a software stack with standardised software interfaces according to IMA concepts was introduced that provides additionally the software interfaces required by the legacy software on top of IMA. On the original mission computer the software accesses the databusses directly via memory mapped I/O. This is no longer possible with a layered software architecture. With the implemented IMA software stack I/O is transmitted to a dedicated module via VME backplane. Calls to the hardware specific I/O drivers are handled on that module and responses replied back to the application software. The paper presents the results of timing and performance measurements with both the legacy and new software architectures on the respective target hardware. The points that need special interest when specifying the hardware, supplier provided software and when implementing the IMA software stack are discussed.

Introduction

The avionics software that is analysed is a mission software running of a proprietary avionic computer in a military fighter aircraft. The avionics system is a federated architecture where the avionic computers are connected via busses. The avionic computers have a high functional integration and complete subsystem functionality may be allocated to a single computer. With this kind of architecture changes and extensions are expensive and time consuming. An enormous effort is spent on integration. For avionics the rapid development of computer technology is both a blessing and a curse. On one side it provides the computing power necessary to utilize advanced algorithms. On the other side the lifetime of computer components is much shorter than that of an aircraft, especially a military fighter aircraft. The lifetime of aircrafts is measured in decades whereas the components may become obsolete during development.

To improve reusability of software and ease migration to new platforms a software stack according to IMA concepts is introduced that allows the mission software to become hardware independent. This is realised on a new hardware platform that is free of obsolescence and provides the required processing capabilities for future enhancements. To reduce risk the legacy software should be migrated with possible no changes.

Hardware Architecture

The mission computer interfaces comprise two dual redundant databusses, direct digital links (discretes) and power supply. The databusses are realised according to STANAG 3838/3910. The discretes specification is STANAG 3909. The new and legacy mission computers have the same shape and connectors.

Mission Software Architecture

The mission software is designed for optimal resource utilisation, flexibility and hardware independence. It is implemented in Ada. The software is decomposed into modules that can be allocated to any processor. Each module is controlled by one or more Ada tasks and communicates with other modules via message queues. The complete software is input triggered. So called Target Specific Ada Packages (TSAP) allow full control of the STANAG 3838/3910 bus. The hardware independence of functional modules is reached by the software design. The modules Input and Output that access the external bus have a low dependency to the underlying hardware. Due to the mode of operation of a STANAG 3838/3910 bus the Bus controlling and moding is highly dependent not even to the hardware but also to the other computers that are connected to the bus.

Runtime Environment

Legacy Ada Runtime and TSAP

Ada Runtime: On the legacy hardware the mission software is compiled and linked with a bare board Ada runtime that provides hardware initialisation and task scheduling. TSAP: The TSAP operations directly access the bus interfaces via memory mapped I/O. Interrupts can be generated by the bus interface module and are routed via backplane to the respective processing module.

Message Queues

On the legacy hardware the mission software is evenly distributed to several 68020 processors. The message queues are implemented using global memory that is accessible for each processor. On the new hardware the complete mission software is running in one program on a single processor. This allows to use an analogue message queue implementation with local memory. The communication between software modules is not affected by the introduction of the IMA architecture.

IMA Architecture

An open standardised software architecture is introduced with the new hardware based on a commercially available real time operating system (RTOS) that provides time and space segregation. The IMA software follows Allied Standard Avionics Architecture Council (ASAAC) standards that are under consideration as NATO Standard Avionics Architecture (STANAG 4626,reference [1]). The communication services provide virtual channels that are independent from the location and number of receivers. A protocol between instances of the Operating System Layer ensures that this is fulfilled. The instances of the Operating System Layer that reside on different processors communicate via transfer connections that are accessed via the Network Independent Interface. A virtual channel can be configured in a way that every message is acknowledged to the sender when it was successfully written to the receivers message queue. An instance of the IMA software stack runs on each processing module and on the bus interface module.

IMA Implementation of Target Specific Ada Packages

The Target Specific Ada Packages required by the mission software are implemented utilising virtual channels. Two different implementations exist with respect to the virtual channel usage. In either case the actual bus access is performed on the bus interface module.

Remote Procedure Call Implementation: The first implementation provides the TSAP operations as a remote procedure call. In and out parameters of the TSAP operations are encapsulated into messages that are transmitted via virtual channel. There is a single virtual channel to send commands to the bus interface module. A dedicated virtual channel to receive responses for a command is assigned to each task that calls TSAP operations. The complete error handling is performed by the mission software. Figure 5: TSAP Implementation as RPC Mapping of Bus Messages to Virtual Channels: The second implementation directly maps input and output messages to dedicated virtual channels. The mapping of virtual channel identifiers to STANAG 3838/3910 bus messages is part of the IMA runtime configuration. Input messages are sent from the bus interface module to the respective virtual channel without acknowledgement. The virtual channels operate overwriting. Any message that arrives overwrites the previous one as it is also the case in the receive buffer on the bus interface module. There is no interaction with the mission software, so error handling needs to be performed by the IMA software stack. Output messages are sent by the called TSAP operation to the respective virtual channel. The mission software gets a feed back from the bus interface module by acknowledgement. The error handling of output messages can still be performed by the mission software.

Analysis of Measurement Results

The frequency of calls for the various message sizes is similar in the three result sets. Approximately the same number of messages and amount of data is transmitted in each case.

Legacy Hardware

On the legacy hardware the TSAP operations directly access the bus interface. There is no latency due to context switches or signalling to another processor. The processor is occupied during the complete TSAP call transferring data to the bus interface. The deviation of the call duration is small. The existing deviation and the maximum call duration results from tasks with higher priority competing for processing time. The maximum call duration is a multiple of the average.

IMA Implementation 1

With the IMA implementation 1 the bus messages are transferred to / from the bus interface module. The processor is not fully occupied during the call.

The request to read / write a message is transmitted via transfer connection to the bus interface module.

The processor is free for other tasks while the calling task is waiting for the response. So the call duration is not pure processing time but includes the communication with the bus interface module. The minimum call duration that is approximately half of the average denotes that requests are queued. This queuing adds to the deviation that is generated from multi tasking already observed on the legacy hardware. As a result the deviation is higher compared to the legacy hardware. The call duration for input messages with the IMA implementation 2 gives an impression of the processing time that is required on the processing module.

IMA Implementation 2

Input and output have to be distinguished for IMA implementation 2 as they are different in operation. Input Messages: To process the TSAP call the latest message received from the bus interface module is read from the local virtual channel buffer. The transmission from the bus interface module to the processing module happens in the background and is not measured. This implementation makes best use of the new hardware and the IMA software architecture. The lowest minimum and average call duration is measured here. Maximum call durations that are a multiple of the average can still be observed due to tasks competing for processing time.

Output Messages: The implementation and measurement results are similar to the first IMA implementation. Even when using a dedicated virtual channel for each output message the requests are queued for transmission through the transfer connection and processed sequentially on the bus interface unit. The small improvements in the call duration may result from the reduced load of the bus interface module due to the different handling of input messages. Another reason may be that the adaptation of TSAP calls to the hardware device driver of the bus interface module is performed on the processing module, which has a higher performance.

Conclusion

The mission software runs successfully on the legacy hardware and on the new hardware with both of the IMA implementations. The bus messages are read and written with the required rates. There is sufficient processing time for functional modules.

The measurement provides indications for the optimisation of both the mission software and IMA software stack.

The limiting factor on the legacy hardware is processing power and bandwidth. The call duration increases significantly with growing message sizes. Therefore the software is optimised for small message sizes to a certain extent. On the new hardware the size of messages is no longer a problem. Modern hardware has the ability to handle higher amounts of data. Despite the higher processing power of new hardware a layered IMA software architecture introduces latencies. As a consequence the number of messages becomes more relevant, which conflicts with the optimisation of the mission software for small but many messages.

The latencies can be minimised by the design of the IMA software stack. The duration for reading input messages with the second IMA implementation displays that, bearing in mind that the transmission of messages from the bus interface unit to the receiver of the virtual channel is no longer measured. Only a small improvement in access times can be observed for output messages in the second IMA implementation because writing the output messages still implies waiting for the acknowledgement from the bus interface module. To get an acknowledgement enables the mission software to detect errors and handle them adequately with a situation awareness that an generic software like the IMA software stack can not achieve. The error handling implemented in the legacy mission software can be reused and provides a safety that can not be designed into the IMA software stack without modifications to the mission software as well.

The hardware specification needs to address the requirements of the IMA software architecture. The hardware must be capable to handle a high number of interrupts and task switches with low latency.

The IMA implementation must be designed that it requires as few as possible context switches. On the other hand it must ensure safety and reliability, which may mean to accept the latencies this implies.

Acknowledgement

Special thank goes to the colleagues at EADS Deutschland GmbH: Markus Moser and Mark Beerling for the active support of the time measurement Gert Wiegert for his helpful annotations.

[

Figure 1 :

 1 Figure 1: Mission Computer Legacy Hardware: The legacy computer is equipped with two different kind of modules on a VME backplane. The processing modules have a Motorola 68020 processor. The memory mapped I/O registers of the passive bus interface module is accessible by each processor. New Hardware: The new computer is equipped with processing modules and an active bus interface unit on a VME backplane. The bus interface module is operated with a PowerPC 405 processor. The processing modules have a PowerPC 750 processor.

Figure 3 :

 3 Figure 3: Example of Software ModulesThe hardware independence of functional modules is reached by the software design. The modules Input and Output that access the external bus have a low dependency to the underlying hardware. Due to the mode of operation of a STANAG 3838/3910 bus the Bus controlling and moding is highly dependent not even to the hardware but also to the other computers that are connected to the bus.

Figure 4 :

 4 Figure 4: ASAAC Software Architecture The RTOS is integral part of the IMA software implementation as it provides vital services such as

FigureFigure 10 :

 10 Figure 8: Average Times of Input Task 1

For the first call of END_TIME:

For succeeding calls of END_TIME:

The incremental calculation achieves the best results when values are near the average from the beginning, which is likely for this measurement.

Measured Operations

During the migration of the mission software to the new IMA software architecture access to the STANAG 3838/3910 bus has been identified as a possible performance bottleneck. Therefore the measurement focuses on reading and writing data on the bus. The TSAP provides four operations to read and write.

• GET_MIL

• PUT_MIL

• GET_EFABUS

• PUT_EFABUS

The operations can be used in synchronous and asynchronous mode. In synchronous mode the operation blocks until the data is actually transmitted by the bus. Therefore only asynchronous mode is suitable for timing and performance measurements.

The majority of calls to the operations is performed by modules Input and Output. Calls by module Bus controlling and moding are not significant for this analysis. In module Input two tasks are reading different bus messages. In module Output there is one task that updates the bus messages after it collected the data from the functional modules.

The duration and frequency of asynchronous calls in dependency to the data size were measured. The message size in 64 Byte blocks is used as element index in calls to the profiling package. The duration is measured by taking the start time, performing the call, taking the end time and updating the statistics.

• Take start time

• Perform asynchronous call

• Take end time

• Update statistics

The frequency is the duration between two calls. It is measured by taking the end time, updating the statistics, taking the start time and performing the call.

• Take end time

• Update statistics

• Take start time

• Perform asynchronous call

In this way for the first call the interval measured for the frequency is the time since initialisation of the time measurement. This introduces a deviation that is negligible for the large number of calls.

The measurement starts 30 seconds after start up of the mission software and is performed over 300 seconds.

Measurement Results

At a first view on the measurement results the new hardware with the IMA software architecture looks worse than the legacy hardware. Why this is not the case is discussed in detail in the next section.