Model Based Engineering of Ground Based Risk Mitigation System

Transcription

1 Model Based Engineering of Ground Based Risk Mitigation System Hassan Reza, Feifei Gu, and Mark Askelson School of Aerospace Sciences University of North Dakota USA Abstract In this paper, we describe how AADLs can be extended by using Colored Petri Nets (CPNs) to simulate the behavior of an avionic system known as the Ground Based Risk Mitigation System (GBRMS). To this end, we provide a set of simple mapping rules that can be used to translate AADL representations of a system to CPN representations. The CPN representation of a system then has been used to simulate the dynamic behaviors of the GBRMS. Keywords: ADL, AADL, Color Petri nets, Model- Based Engineering, OSATE, Aerospace Software Engineering, Simulation, Behavioral Modeling. 1. INTRODUCTION Architectural Analysis and Description Languages (AADLs) and the supporting toolset known as OSATE (Open Source Architectural description Tool Environment) are model-based system engineering notations and environments that are becoming an essential part of developing highly complex and safety critical systems. The design of AADLs was motivated by the need to specify and analyze the various quality or dimensions of a safety critical system in an integrated environment in which both core hardware and software elements of a system can co-exist. This coexistence feature, in turn, will provide, among other things, a common ground that facilitates the communication among stakeholder (e.g., software, hardware, and control engineers) and increases productivity, reuse, and maintainability by promoting software engineering principles (e.g., abstraction, modularity and locality, and separation of concern). AADL is based on many years of collective work and experiences with ADL (architectural description language) [1] [2] [9]. AADL was originally developed by the Honeywell Corporation under SAE (Society of Automotive Engineers). The underlining formal theory of AADL is based on MetaH [3] [6] [8] [9], which is a domain specific ADL used for specification and verification of RT systems. In general, the AADL-SAE (see appendix A) standard has provided (at least) the following features: 1. Supports model representations (e.g., textual and graphical); 2. Provides an XML interchange format that allows model transformations, integrations, and/or navigations between different models (e.g., textual to graphical representation or vice versa); 3. Provides a UML [4] profile representing AADL as a specialized modeling notation within UML/MDD [13]; 4. Supports integrateability with existing commercial and/or open source tool solutions and plug-ins written in [11][12]; 5. Supports agreement with various programming language (e.g., Ada and C);

2 6. Supports an error model annex to model and analyze the reliability and safety of a system. Using OSATE, an engineer is able to perform (at least) the following tasks: translate AADL to MetaH, syntactic consistency analysis, performance analysis, safety analysis, security analysis, and reliability analysis. Although AADL and its tool support, OSTATE, support many of features that are required for simulating, prototyping, and analyzing the quality of a system at a high level of abstraction, AADL and OSTATE lack a very important capability needed to simulate and/or analyze the functional correctness of a system. This shortcoming of AADL-OSATE is attributed to the limitation of MetH (underlying formal theory of AADL). This deficiency of AADL may result in serious problems because the development of safety and mission critical systems demands the highest level of dependability. On the other hand, Color Petri Nets (CPN) are a high class of Petri Nets having well-defined semantics with precise representation of places, transitions, arcs, and inscriptions (i.e., collective term to refer to the tokens, their types and values, constraints, and functions/expressions) [5]. CPN (see Appendix B) has a well-established body of theoretical work and results for specification and verification of static and dynamic behavior of highly complex and concurrent systems in various domains such as manufacturing, avionics, military, and medicine. Using CPN engineers should be able to apply CPN theory and supporting tools to prove the properties of the system under construction (e.g., the absence of livelock/deadlock). CPN Tools provides a platform for editing, simulating, and analyzing CPN models in both academic and industrial fields. CPN Tools consists of two main components--a graphical editor and a backend simulator component. Using CPN simulator tools, the Petri nets engineer should be able to investigate property of Petri nets (i.e., firing of transitions) [20]. Therefore, it makes sense to extend AADLs with the analysis capability of CPNs to automatically simulate/analyze the dynamic behavior of AADLs. This paper is structured as follows: the next section describes the approach to extend AADL s capability, section 3 describes the practicality of our method using an avionic system known as Ground Based Risk Mitigation System (GBRMS in sequel), section 4 discusses related work, and section 5 provides conclusions and future work. 2. METHOD: DYNAMIC BEHAVIORAL ANALYSIS OF AADL USING CPNS Model-based engineering development utilizes formal modeling and state of the art toolsets to verify the behavior of a system so as to automatically generate code from specification and to generate test cases for system testing and validation [6][7]. Our framework supports the generation of formal models for specification and verification of both functional and nonfunctional requirements of a critical system by mapping AADL representation to Color Petri Nets (CPNs) [5]. More specifically, we have designed a simple set of mapping rules from AADL-to-CPN. The justifications for using CPNs are very obvious. CPN is a wide-spread formal modeling language with very well established analysis results and supporting tools (editor, model checker, etc.). Color Petri Net models have been extensively used for specifying and analyzing complex, concurrent, distributed, asynchronous, parallel, deterministic, and non-deterministic systems. Using the analyzability capability of CPNs, such as reachability/coverability graph analysis, Petri net modelers are able to identify the presence of unsafe state (markings) that may jeopardize the safety of a system as a whole. An important issue is the identification of a minimum subset (or core) of AADL components that can be faithfully mapped to the main elements of CPNs. Thus, proper decisions need to be made regarding what constitutes the subset of AADL and how this subset can be mapped to CPN for formal reasoning. For example, various types of interfaces and nesting rules used to create AADL

3 models may violate rules and principles governing systematic construction of CPN models. Core AADL s elements include hardware and software components of AADLs such as processes, threads, bus, memory processors, etc. For the purpose of this work, AADL core elements consist of two sets of elements--active and passive components. Active elements are those elements having functional capabilities. Passive elements are those elements that are incapable of initiating or performing any task. Examples of active elements include threads and processes. Examples of passive elements include memory, buses, and devices. Therefore, it makes sense to extend the capabilities of AADL-OSATE, a model-based engineering tool set, with CPNs to validate both the functional and nonfunctional features of the system. CPN models and their tool supports allow us to analyze behavioral aspects of a system. More specifically, by constructing a reachability graph obtained from AADL-CPNs models and using existing reduction techniques and tools, we should be able to analyze essential properties of a system design, such as verifying the absence of deadlocks and livelocks. 3. CASE STUDY: THE DEVELOPMENT OF GBRMS A study has shown that ground and midair collision risk associated with the operations of Unmanned Aircraft System (UAS in sequel) may meet target levels of safety by integrating mitigation mechanisms into the system [16]. To this end, the goal of UAS-GBRMS is to provide a UAV operator with the level of awareness needed to prevent potential mid-air collisions among various aircraft (manned and unmanned) flying in the national airspace system (NAS). In the simplest form, UAS-GBRMS is supposed to monitor the airspace in order to calculate the risk of mid-air collisions. The risk is computed using numerous parameters such as the number of aircraft, the capabilities of aircraft, and the characteristics of airspace together with a proper encounter model. The main components of the UAS-GBRMS system architecture (figure 1) include acquisition of real-time data provided by radars and ADS-B receivers in order to monitor the flight paths of UAV. Several factors may jeopardize the safety of operations that are supported with the UAS- GBRMS. These factors include: a) possible overlap between flight paths of UAV and manned aircrafts (in sequel MAV) or other UAV; b) the UAV may simply run out of gas; c) mechanical limitation and weather conditions may result in inaccuracy about UAV flight path, unpredictable events, and traffic density. These factors may require a rapid course of action to be taken by UAVs in order to maintain the expected level of safety. The UAS-GBRMS falls into the category of mission and safety critical systems because any deviation (minor or major) from functional and nonfunctional requirements can be easily translated into a fatal crash and loss of life. As such, the dependability, assurance methods and modeling, and standards (e.g., Do-178B) are mandated by various organizations (e.g., FAA) to guarantee a certain level of safety. The expected (or target level of) safety and reliability for avionic systems can be specified numerically using a possible range of values or max/min allowable values (e.g., 5 failures for every 7522 hours of flying or ). An example of other nonfunctional requirements (NFR) includes performance failures (end-to-end flow or communication failures). Figure 1 shows the informal system architecture of the UAS-GBRMS that provides the required functionality. In this figure, radars constitute the primary sensors for collecting data about the UAVs and MAVs. The software architecture that provides full processing is composed of two blocks (dashed rectangular): 1) primarily radar capability and 2) command and control system which consists of a) the Data Fusion subsystem, b) the Risk mitigation subsystem, and c) the Display subsystem. In figure 1, a data link provides the required communication between radar system and command and control subsystems.

4 figure 1. Once the AADL specification is constructed, we map the AADL specification to CPN according to the mapping rules (see table 1). Mapping is accomplished by replacing threads, processes, devices, etc., with the appropriate CPN notations according to table 1. Figure 1. The Generic Architecture of UAS-RMS The risk mitigation subsystem is responsible for computing the risk associated with operating in the NAS. The data fusion subsystem is responsible for combining and maintaining all data sent by various devices (e.g., Radar site). The display or visualization subsystem displays information to range and other UAV operators (and stores data). As can be seen in the figure, there are five input devices connected to the GBRMS: UAV-GPS (receiver device to collect UAV location from GPS), GPARS-Radars, Weather Radar, Weather Station and ADS-B Receiver (device to collect ADS-B data from participating aircraft). After processing in the GBRMS, all of the final data are sent to three output devices: the GOIDS (Ground observer interactive display system), RCCIDS Range Control Center Interactive Display System), and WXIDS (Weather Interactive Display System). The GOIDS is an interactive display of the GPAR-RMS for the UAV operator; the RCCIDS is interactive display of the GPAR-RMS for rang operator; the WXIDS is an interactive display for range control operator that displays weather radar data. Inside the GBRMS, the three subsystems talk to each other. Inside each subsystem, there are some processes and threads to process data and to transmit data or event information from/to each other. Using the process discussed in the previous section, we first create an AADL specification of UAS-GBRMS from the informal one shown in AADL Components Ports (in/out data/event port, port group, event data port, data access) System Process Thread Device Memory Bus (physical connection) Connections Processor Mapping CPN Elements place Hierarchy transition (which includes the substitution transitions) or transition Hierarchy transition or transition Transition Transition Place Flows Flows Transition Table 1: Rules for mapping between AADL and CPN The following example (figures 2 and 3) shows how to map AADL to CPN according to the mapping rules. The CPN places model the features part of threads, so the in data port weather_radar_input mapped to the place with the corresponding name. We do the same to the out data port weather_radar_output. CPN transition models the thread itself. The thread weather_radar_polling is mapped to transitions having the same name. Finally, arcs are used to model the connection. Using operational scenarios documented during requirement analysis, we identify various states (i.e., initial marking) of the GBRMS by adding the required tokens and inscriptions to the CPN model in order to validate the dynamic behavior of our system.

5 100 ms Weather_Radar_Polling port to the data manager process. This process, in turn, will send the result of analysis to the GOIDS The weather station sends its data via an output port to the weather radar polling thread, which then sends its analysis result to the WXIDS. The data polling thread sends the data gathered from other processes to the RCCIDS. Figure 2: Example of AADL thread component Figure 3: CPN graph transformed from AADL thread component The following narrative informally describes an operational scenario where within the detecting range of the radar there is one MAV and one UAV. They both are flying at the same altitude and at the same speed but in opposite directions. The system receives the position of the UAV and MAV, namely (x i, y i, z i ) coordinates from the external devices (e.g., radar site). The coordinate values fused with other information (e.g., weather information) are used as the initial markings of the CPNs model. Using the values of x, y, and z, the system calculates the minim allowable separation distance between these planes needed for a possible mid-air collision to occur. In this case, the separation distances associated with a possible mid-air collision are <500 ft vertically and <1000 ft horizontally. With this, the system provides feedback to militate against mid-air collisions. Figures 4-11 depict high- (abstract) and low- (concrete) level architectural and design specifications in AADLs and CPNs respectively. Figure 4 shows the high level architectural representation of the GBRMS system. In this figure the devices such as UAV, GPAR, and ADS- B Receiver provide data and events via output ports to the Airspace Data Fusion process. The weather radar sends data and events via an output Figure 4: First Level Software View Figure 5: CPN Corresponding to Figure 4 Figure 5 shows the mapping from AADL to CPN. The transition RMS is a super transition corresponding to the system elements of AADL shown in figure 5 and hence can be hierarchically refined into another CPN or page (see figure 7). UAV-GPS STATUS, GPAR-RADAR STATUS, ADS-B-RECEIVER STATUS, WEATHER- STATION STATUS, and WEATHER-RADAR- STATUS are input places (or input data interfaces of the GBRMS system). Colorset NN is a record type that describes the positions or the coordination of the UAV; this information can be used to identify whether the UAV is flying within the detectable range of radar. Colorset MM is a

6 record type that holds the positions of an MAV within the range of radar. Colorset WS is a record type that includes weather information such as wind direction, temperature, etc. Color-set DATA is a string type that provides some information. Figure 7: CPN Corresponding to Figure 6 Figure 6: Second Level Software View Figure 6 represents the concrete view of the GBRMS shown in figure 4. There are three main subsystems: RMSS, Data manager subsystem, and Airspace data fusion subsystem. The Airspace Data fusion subsystem performs the following tasks: fusing aircraft position data using optimal fusion algorithms; collects and maintains all of the data coming from the UAS polling thread, Radar polling thread, and ADS-B polling threads; sends the final data to the other two subsystems--namely the RMSS (Risk Mitigation Support System) and the display subsystem. In figure 6 the RMSS computes risk computations. To this end, it receives data from the data fusion system it then sends the final result to the data manager process. The Data Manager Process is in charge of gathering all information and displaying this information to a range control or ground observer operator and stores data. There are three threads in the Data Manager Process: the data fusion polling thread, the RMSS polling thread, and the weather polling thread. These three threads send data to storage. The two different kinds of Data polling threads read the data from storage and send them to the RCCIDS and GOIDS respectively. The Weather Radar polling thread gathers external weather radar data from Weather Radar and sends them to WXIDS, which is an interactive display of external weather radar data for the range control operator. The detailed design of the transition RRMS in figure 6, are illustrated in figure 7. In this figure the arc expression is added, where n is a variable of type NN, m is a variable of type MM, p is a variable of type WS, and str is a variable of type DATA. DM and ADF are another two hierarchical transitions that are replaced by the subpages illustrated in figures 9 and 11. Figure 8: Third Level Software View-Data Manager Process Figure 8 shows the detailed description of the Data Manager Process. The Data Manager Process receives comprehensive data regarding aircraft positions with a sporadic thread (the Data fusion polling thread), updates these data, and stores them in storage. The sporadic thread RMSS polling thread receives data from RMSS, updates data, and retains them in storage. The weather polling thread is a periodic thread. It receives data

7 from the Weather Station device, updates the data every 100 ms, and saves them in the storage. Two kinds of Data polling threads read the data from storage. Figure 10 shows the detailed description of Airspace Data fusion process. The periodic thread UAS polling thread receives data from UAV every 100 ms, updates the old information, and saves the new data in storage. The Radar polling thread and ADS-B polling thread perform the same set of tasks as Airspace Data. Figure 9: CPN Corresponding to Figure 8 Figure 9 shows the detailed design of the transition DM (i.e., Data Manger) where Place A represents the input data interface of storage. It connects to the transition SAVE, which performs the saving task. GOID-STATUS and RCCIDS-STATUS are output interfaces of data manager process. They access storage to get the data and then send them to different data polling threads. Figure 11: CPN Corresponding to Figure 10 Figure 11 shows the detailed design of the transition ADF. When a record is transmitted to UAV_ADF_INPUT, the system will make a decision according to the value of q. where q is Boolean where q=false means the absence of UAV; q=true means the presence of UAV. If a UAV is not within range of radar, transition FALSE1 will return empty to UAV_INPUT. Otherwise, the rest of the record is transmitted to the next place UAS_ADF. The same thing happens to the place of ADS_B_INPUT. The CPN figures used in this paper were edited, simulated, and analyzed by using CPN Tools [15]. 4. RELATED WORKS Figure 10: Third Level Software View-Airspace Data Fusion Process There have been some work to enhance the capability of an AADL-based notation and tool set; the tool set is named Ocarina/Cheddar [10] has been used to prototype and implement a distributed real-time system. The authors informally discussed the mapping between AADLs and CPNs.

8 In [18] the author proposes a general methodology for translating AADL to BIP, which focuses on threads, processes, and processors as well as the behavioral annex. The work reported in [19] is yet another attempt for translating AADL into Petri nets. 5. CONCLUSION AND FUTURE WORK In this paper we have shown how AADL specifications can be extended by using CPN modeling notations to simulate the dynamic behavior of a system called the GBRMS. In order to extend AADL with CPNs behavioral analysis and specifications, we devised a simple set of mapping rules to create the structure of CPN. We used operational scenarios documented during requirements engraining to extract initial marking and CPN inscriptions. These are used to describe AADL CONCEPTS APPENDIX A: AADL AADL DIAGRAM AADL DESCRIPTION dynamic aspects of CPN--namely token games. We applied our method in the development of the GBRMS. The mapping of AADL-to-CPN is performed manually. Our ultimate goal is to automate the behavioral verification of an avionic software system known as GBRMS. Currently we are developing an Eclipse [11] plug-in to fully automate the mapping from AADL to CPN. To this end, we are investigating the feasibility of model driven and model transformation techniques to map AADL-XML representation of a system into Petri Nets Mark-up Language (PNML), which is a standard interchange format for Petri net tools. The main goal of the ISO/IEC [17] standard is to promote the extensive acceptance of different classes of Petri nets.. DEVICES CONNECTIONS APPENDIX A: AADL (CONTINUED) Represent external components such sensors and radars Represent Connects ports in the direction of their flows SYSTEM PROCESS THREAD THREAD GROUP Represent composite or hierarchical structure of a components a protected virtual address Represents schedulable unit of concurrent execution of code Represents Collection of threads PORTS DATA PORT PORTS GROUPS EVENT DATA PORT DATA ACCESS Represent input and output interface Represents a collections of input/out places DATA Represents sharable data APPENDIX B: CPN SUBPROGRAM MEMORY BUS Represents Callable unit of sequential code Represents data storage retaining data values represents communication channels among hardware elements Formal Definition: A Colored Petri Net is a ninetuple CPN = (, P, T, A, N, C, G, E, I) where = a finite set of non-empty types, P = a finite set of places, T = a finite set of transitions, A = a finite set of arcs (or flows) connecting places to transitions or transitions to places, N = a node function and is defined from A into P T P T.

9 C = a color function. It is defined from P into, G = a guard function, E = an arc expression function, I = an initialization function. ACKNOWLEDGMENT This work was partially funded by the United States Air Force under Contract Number FA R-C003. REFERENCES [1] P. FEILER, D. CLUCH, J. HUDAK. THEARCHITECTURE ANALYSIS & DESIGN LANGUAGE (AADL): AN INTRODUCTION. CMU/SEI-2006-TN-011. [2] M. SHAW, D. GARLAN. SOFTWARE ARCHITECTURE: PERSPECTIVE ON AN EMERGING DISCIPLINE, PRENTICE HALL [3] P. FEILER, B. LEWIS, AND S. VESTAL, IMPROVING PREDICTABILITY IN EMBEDDED REAL-TIME SYSTEMS, CARNEGIE MELLON SOFTWARE ENGINEERING INSTITUTE, CMU/SEI-2000-SR-011, OCTOBER [4] G. BOOCH, J. RUMBAUGH, I. JACOBSON. THE UNIFIED MODELING LANGUAGE USER GUIDE. ADDISON WESLEY, [5] K. JENSEN. COLORED PETRI NETS: BASIC CONCEPTS, ANALYSIS METHODS AND PRACTICAL USE VOL.1, 2ND EDITION, SPRINGER, [6] S. VESTAL. METAH PROGRAMMER S MANUAL, VERSION HONEYWELL TECHNOLOGY CENTER, METAH MATERIAL IS AVAILABLE UPON REQUEST. [7] M. UTTING, AND B. LEGEARD. PRACTICAL MODEL- BASED TESTING: A TOOLS APPROACH. MORGAN KAUFMAN [8] M. BARBACCI, AND C. WEINSTOCK. MAPPING METAH INTO ACME. SPECIAL REPORT CMU/SEI-98- SR-006. [9] N. MEDVIDOVIC, AND R. TAYLOR. A CLASSIFICATION AND COMPARISON FRAMEWORK FOR SOFTWARE ARCHITECTURE DESCRIPTION LANGUAGES. IEEE TRANSACTION ON SOFTWARE ENGINEERING, THE OCARINA AADL TOOL SITE. IEEE TRANSACTIONS ON EMBEDDED SYSTEM. VOL.7, NO.4. JULY [11] D. CARLSON. ECLIPSE DISTILLED. ADDISON WESLEY, [12] OSATE UPDATE SITE AT SEI: TES-PREVIOUS.HTML. [13] OBJECT MANAGEMENT GROUP (OMG). [14] KURT JENSEN. A BRIEF INTRODUCTION TO COLOURED PETRI NETS. COMPUTER SCIENCE DEPARTMENT, UNIVERSITY OF AARHUS. NYMUNKEGADE, BLDG. 540, DK-8000 AARHUSC, DENMARK [15] CPN-TOOL: WESTERGAARD.EU/WP CONTENT /UPLOADS/2010/09/CPN-TOOLS.PDF. [16] R. WEIBLE, R. HANSMAN. AN INTEGRATED APPROACH TO EVALUATING RISK MITIGATION MEASURES FOR UAV OPERATIONAL CONCEPTS IN THE NAS. AIAA S 4TH INFOTECH@AEROSPACE CONFERENCE 26-29, [17] A PRIMER ON THE PETRI NET MARKUP LANGUAGE AND ISO/IEC L. HILLAH, E. KINDLER, F. KORDON, L. PETRUCCI AND N. TRÈVES. PETRI NET NEWSLETTER 76:9--28, OCTOBER [18] M. CHKOURI, A. ROBERT, M. BOZGA, J. SIFAKIS. TRANSLATING AADL INTO BIP- APPLICATION TO THE VERIFICATION OF REAL-TIME SYSTEMS. IN PROC. OF MODELS ACES-MB-MODEL BASED ARCHITECTING AND CONSTRUCTION OF EMBEDDED SYSTEMS, [19] BERTHOMIEU, B., BODEVEIX, J.P.,CHAUDET, C., DAL-ZILIO, S., FILALI, M., VERNADAT, F.: FORMAL VERIFICATION OF AADL SPECIFICATIONS IN THE TOPCASED ENVIRONMENT. IN: ADA-EUROPE 09. LNCS, VOL SPRINGER (2009). [20] K. H. MORTENSEN. EFFICIENT DATA-STRUCTURE AND ALGORITHMS FOR A CPNS SIMULATOR. 3 RD WORKSHOP AND TUTORIAL ON PRACTICAL USE OF COLORED PETRI NETS AND CPN TOOLS, [10] J. HUGUES, B. ZALILA, AND L. PAUTET. FROM THE PROTOTYPE TO THE FINAL EMBEDDED SYSTEM USING