Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems SAn. To. S Laboratory, Kansas State University, USA http: //www. cis. ksu. edu/cadena Principal Investigators Matt Dwyer John Hatcliff Gurdip Singh Postdocs and Students Radu Iosif Hongjun Zheng Corina Pasareanu Georg Jung Robby Venkatesh Ranganath Oksana Tkachuk William Deng Support US National Science Foundation (NSF) US National Aeronautics and Space Agency (NASA) US Department of Defense Advanced Research Projects Agency (DARPA) US Army Research Office (ARO) Rockwell-Collins ATC Honeywell Technology Center and NASA Langley Sun Microsystems Intel
Distributed Components Network
Distributed Components Java Interface Definition Language (IDL) specifications for remote methods C++ C Middleware (e. g. CORBA) Automatically generated proxies C Java C++
Distributed Components Java C++ Event Service C Transaction Service Middleware (e. g. CORBA) Component Interface Definition Language (CCM IDL) substantial portion of code auto-generated Naming Service C Synchronization Service Java C++
Checking CCM Systems Modern Software Systems Java C++ Our Themes C n n Transaction Service Event Service Middleware (e. g. CORBA) Naming Service n Synchronization Service n n C n n Java Light-weight behavioral specifications Leverage abstractions that programmers already write C++ These systems are huge! What are appropriate abstractions/specifications and how can we get programmers to write them? Component IDL Scale static analysis techniques to handle remote connections Use emerging model-checking technology dedicated to OO structures and RT scheduling algorithms
Analysis & Verification of Fighter Aircraft Mission Control Systems n n Mission-control software for Boeing military aircraft, e. g. , F-18 E/F, Harrier, UCAV Boeing’s Bold Stroke Avionics Middleware n n …built on top of ACE/TAO RT CORBA Our focus: developing a rigorous design process with formal design artifacts that can be automatically checked for common design flaws
Boeing Bold Stroke Platform Periodic & Aperiodic Many Computers Focus Domain Nav Sensors Multiple Safety Criticalities Weapon Management Information Security Multiple Buses Mission Computer Vehicle Mgmt Weapons Hard & Soft Real-Time Constrained Tactical Links Data Links Radar COTS O(106) Lines of Code
Control-Push Data-Pull Typical situation Component A computes some data that is to be read by one or more components Bi data. Available B 1 get. Data() A data. Available get. Data() Run-time Actions A publishes a data. Available event Bi call the get. Data() method of A to fetch the data Bk
Control-Push Data-Pull Structure 1. Logical GPS component receives a periodic event Input indicating that it should read the physical GPS device. 1 2. Logical GPS publishes DATA_AVAILABLE event 2 3. Airframe component fetches GPS data by calling GPS Get. Data method 4. Airframe updates its position data and publishes DATA_AVAILABLE event 3 4 6 5. Nav. Display component fetches Air. Frame data by calling Air. Frame Get. Data method 4 5 Output 6. Nav. Display updates the physical display
Larger Configuration …moving up to 1000+ components
Development Process Component Development Component Integration Platform-specific Components Common Components 100+ developers Real Board Testing Test real-time aspects, frame-overruns, etc. Connect components, assign priorities, locking schemes, distribute Analysis & Functional Testing Debuggers, call-graph analyzers, scheduling tools
Research Context n Provided with an Open Experimental Platform (OEP) from Boeing n n n Provided with 150+ page document that outline development process and describe challenge problems Must provide tool-based solutions that can be applied by Boeing research team to realistic systems Must propose solutions that fit within current development process, code base, etc. Must propose metrics for tool performance and ease of use n n a sanitized version of the real system 100, 000+ lines of C++ code (including RT CORBA middleware) evaluation by Boeing research team Must make significant progress in one year with regular evaluation milestones
Next… Short-comings in Bold Stroke development that we will attempt to address One could imagine doing a number of things. We first focused on items in Boeing’s “wish list”.
Lack of Modeling development bypasses modeling Informal natural language requirements XML component connection information n C++ component library <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> Process moves directly from informal textual requirements documents to C++ coding (!) No use of component-level (CCM) IDL for code generation Still resistance by “legacy developers” to higher-level descriptions (moving away from machine code has been difficult for some)
Unleveraged Artifacts n Current design/model artifacts are used as informal documentation n n not connected to analysis/visualization tools not connected to “glue code” (deployment code) generation
Lack of Model Analysis Boeing OEP Challenge Problems 1. Forward & backward data and event dependencies 2. Dependency intersections 3. Components with high data coupling 4. All components from a particular rate group 5. Cycle checks … 15 -20 others related to dependencies …also mode-aware dependences
Lack of Model Analysis Boeing OEP Challenge Problems If component 1 is in mode A when component 2 produces event E, then component 3 will consume event F (Section 4. 1. 5. 3. 6) A temporal property well-suited for modelchecking!
No Unifying Mechanism C++ Component Code <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> Bold Stroke XML Configurator Info ? Design Artifacts High-level Specification Language Integrated Development Environment Analysis and Qo. S Aspect Synthesis
Cadena CCM Interface Definition Language Java/C++ Component Code <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> Bold Stroke XML Configurator Info RT Aspect Specs State Transitions UML Design Artifacts System Configuration High-level Specification Language Eclipse Plug-In Integrated Development Environment Analysis and Qo. S Aspect Synthesis
Next… Cadena functionality and capabilities…
Example System
Example System Basic components seen earlier
Example System Navigation Steering Subsystem
Example System Tactical Steering Subsystem
Example System on/off Display Control on/off
Outline 4. Modal Behavior 1. Component Interface 2. Component Connections 3. Dependence Information
CCM Component Interfaces n CCM Component Interfaces are based on a notion of ports n Event ports – asynchronous event delivery n n n consumes port – input (event sink) publishes port – output (event source) Interface ports – synchronous method calls n n provides port – provide interface to clients (facet) uses port – use interface of other component (receptacle)
Component Ports CORBA 3 CCM IDL eventtype Time. Out {} eventtype Data. Available {} interface Read. Data { readonly attribute any data; } input event port component BMDevice { consumes Time. Out timeout publishes Data. Available data. Current provides Read. Data data. Out }
Component Ports CORBA 3 CCM IDL eventtype Time. Out {} eventtype Data. Available {} interface Read. Data { readonly attribute any data; } component BMDevice { consumes Time. Out timeout publishes Data. Available data. Current provides Read. Data data. Out } output event port
Component Ports CORBA 3 CCM IDL eventtype Time. Out {} eventtype Data. Available {} interface Read. Data { any get_data(); } component BMDevice { consumes Time. Out timeout publishes Data. Available data. Current provides Read. Data data. Out } provide interface to clients (facet)
Outline 2. Component Connections
Component Connections n Three ways in Cadena n n A textual language for allocating component instances and describing port connections A graphical representation of the same n n n analogous to UML collaboration diagram useful for visualizing dependency information A form-based (spreadsheet-like) view n n useful for component integrator from pull-down menus n n pick ports to connect to pick Qo. S attributes (rates, locations, etc. )
Cadena Component Assembly system Modal. SP { abstract distribution nodes locations l 1, l 2, l 3; rates 1, 5, 20, 60; instance of connect to at. Rate connect to Air. Frame BMLazy. Active on l 2 { data. Available GPS. data. Current 20 data. In GPS. data. Out instance of connect to } … GPS BMDevice on l 2 { timeout Event. Channel. timeout 20
Cadena Component Assembly system Modal. SP { rate group declaration locations l 1, l 2, l 3; rates 1, 5, 20, 60; instance of connect to at. Rate connect to Air. Frame BMLazy. Active on l 2 { data. Available GPS. data. Current 20 data. In GPS. data. Out instance of connect to } … GPS BMDevice on l 2 { timeout Event. Channel. timeout 20
Cadena Component Assembly system Modal. SP { locations l 1, l 2, l 3; rates 1, 5, 20, 60; instance of connect to at. Rate connect to Air. Frame BMLazy. Active on l 2 { data. Available GPS. data. Current 20 data. In GPS. data. Out instance of connect to } … GPS BMDevice on l 2 { timeout Event. Channel. timeout 20 create instance of Lazy. Active component called Air. Frame
Cadena Component Assembly system Modal. SP { locations l 1, l 2, l 3; rates 1, 5, 20, 60; connect event INPUT port of current component to event OUTPUT port of GPS component instance of connect to at. Rate connect to Air. Frame BMLazy. Active on l 2 { data. Available GPS. data. Current 20 data. In GPS. data. Out instance of connect to } … GPS BMDevice on l 2 { timeout Event. Channel. timeout 20
Cadena Component Assembly system Modal. SP { locations l 1, l 2, l 3; rates 1, 5, 20, 60; instance of connect to at. Rate connect to Air. Frame BMLazy. Active on l 2 { data. Available GPS. data. Current 20 data. In GPS. data. Out instance of connect to } … GPS BMDevice on l 2 { timeout Event. Channel. timeout 20 connect data INPUT port of current component to data OUTPUT port of GPS component
Cadena Component Assembly system Modal. SP { locations l 1, l 2, l 3; rates 1, 5, 20, 60; instance of connect to at. Rate connect to Air. Frame BMLazy. Active on l 2 { data. Available GPS. data. Current 20 data. In GPS. data. Out instance of connect to } … GPS BMDevice on l 2 { timeout Event. Channel. timeout 20 create instance of Device. Component called GPS
Cadena Component Assembly system Modal. SP { locations l 1, l 2, l 3; rates 1, 5, 20, 60; instance of connect to at. Rate connect to Air. Frame BMLazy. Active on l 2 { data. Available GPS. data. Current 20 data. In GPS. data. Out instance of connect to } … GPS BMDevice on l 2 { timeout Event. Channel. timeout 20 connect event INPUT port of current component to event OUTPUT port of Event. Channel
Cadena Component Assembly
Cadena Visualization
Code Generation Overview Component Code Generation component BMModal { consumes Data. Available data. In. Ready; uses Read. Data data. In; publishes Data. Available data. Out. Ready; provides Read. Data data. Out; provides Toggle switch; } BM. Device component BMModal { consumes Data. Available data. In. Ready; uses Read. Data data. In; publishes Data. Available data. Out. Ready; provides Read. Data data. Out; provides Toggle switch; } BM. Lazy. Active … component BMModal { consumes Data. Available data. In. Ready; uses Read. Data data. In; publishes Data. Available data. Out. Ready; provides Read. Data data. Out; provides Toggle switch; } BM. Modal “Glue Code” Generation Glue Code Execution gives allocation and deployment of component instances and connections (complete system)
Outline 3. Dependence Information
Dependency Specifications n n n Inter-component dependences are given by connection information (already seen) We now give notation for specifying intracomponent dependencies An example of Meyer’s “something intelligent/useful” that a developer or manager might want to know n n In this case, component integrator leverages this info in a variety of ways to specify aspects such as rates/priorities, distribution, scheduling, etc. Used to visualize system behavior in different modes
Light-weight Dependency Specs dependencydefault == none; dependencies { data. Write. Out. set_data() -> out. Data. Available; } behavior {. . . call on set_data() } triggers out. Data. Available port action
Light-weight Dependency Specs triggers no other actions dependencydefault == all; dependencies { mode. Change() ->; case mode. Change. mode. Var of { enabled: in. Data. Available -> data. In. get_data(), out. Data. Available; disabled: in. Data. Available ->; } } behavior {. . . }
Light-weight Dependency Specs dependencydefault == all; dependencies { mode. Change() ->; case mode. Change. mode. Var of { enabled: in. Data. Available -> data. In. get_data(), out. Data. Available; disabled: in. Data. Available ->; } } behavior {. . . } in enabled mode, shows actions triggered by receipt of event on in. Data. Available port
Light-weight Dependency Specs dependencydefault == all; dependencies { mode. Change() ->; case mode. Change. mode. Var of { enabled: in. Data. Available -> data. In. get_data(), out. Data. Available; disabled: in. Data. Available ->; } } behavior {. . . } in disabled mode, in. Data. Available triggers no other port actions
Aspect Synthesis Dependency-driven rate assignment to event handlers 5 Hz 20 Hz 1 Hz 20 Hz
Cadena User Interface
Outline 4. Modal Behavior
Transition System Semantics n n Boeing engineers want to reason about system/component modes at design time Ideal for model-checking because… n n component modes are finite mode-transitions are triggered by event/data-port actions only tiny portion of system’s state space needs to be exposed Mode-related requirements can be naturally captured in TL or tools like Bell Labs Timeline Editor
Ultimate Modeling View CCM IDL Model Layer Check mode behaviors, temporal properties, timing constraints Code Layer Generate code, fillin skeletons, check for refinement Check that implementations satisfy/refinement high-level specs – leverage the fact that code skeletons are automatically generated We don’t do all of this yet!
Component Behavior input ports component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes {enabled, disabled}; Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } …
Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; output ports enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } …
Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } … mode declaration using CORBA IDL
Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } … behavior for events on data. In. Ready port
Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } … behavior mode cases
Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } … data flow specification
Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } … publish event
Towards a Complete Model We have transition semantics for intra-component behavior. ? How should we model communication layer?
Outline of Real System Event channel with internal thread pool passive components Threads run call-backs associated with event consumer ports Thread Pool … 60 Hz 20 Hz … … 5 Hz 1 Hz … … dispatch queues for each rate group correlation & filtering consumer refs … publish proxy consumer holds list of consumer references
Modeling with Direct OO Support n d. Spin model-checker n n n Model generation strategy n n n automatically generate component models hand-craft event-channel model (only once) Explicitly encode priorities/scheduling/threadperiods into transition system n n supports references, dynamic allocation, garbage collection, heap symmetries built by Radu Iosif (KSU, now Verimag) this dramatically reduces interleavings No modeling of RT/clocks for now n still allows interesting functional properties as suggested by Boeing to be checked
Modeling Strategy Event channel with internal thread pool Thread Pool … 60 Hz 20 Hz … … 5 Hz 1 Hz … … correlation & filtering …
Modeling Strategy Component Models Event Channel Model Connections thru d. Spin References Component Models
DSpin Modeling of Components handles data. In. Ready (Data. Available e) { case m of enabled { any Nav. Steering_internal. Data; modedata. Out: : data <- data. In. get. Data(); Nav. Steering_component. State; push {} data. Out. Ready; ftype Ref_Nav. Steering_data. In 1_get. Data, } Ref_Nav. Steering_data. In 2_get. Data; disabled {} ftype Ref_Nav. Steering_update; } function Fun_Nav. Steering_source 1 (mtype t) { printf("Nav. Steering: source 1 handler invoked. n"); if : : Nav. Steering_component. State == enabled -> Nav. Steering_internal. Data = Ref_Nav. Steering_data. In 1_get. Data (); printf("Nav. Steering: publishing update. n"); Ref_Nav. Steering_update (Nav. Steering_Data. Available) : : else fi } Structure follows component behavior spec and connection representation closely
DSpin Modeling of Connections instance of connect to at. Rate connect to Air. Frame BMLazy. Active on l 2 { data. Available GPS. data. Current 20 data. In GPS. data. Out Modeled very directly in DSpin Ref_GPS_data. Current = Proxy_GPS_data. Current; GPS_data. Current_Number. Subscribers = 1; GPS_data. Current_Subscriber. List = new function. Field[1]; GPS_data. Current_Subscriber. List[0]. Entry = Fun_Air. Frame_data. Available;
Conclusions n Could imagine providing a variety of forms of automated checking of lightweight specs for component-based systems n n Cadena provides currently provides a few – as requested by Boeing engineers Component IDL is a natural level for attaching lightweight specs Spec forms are naturally incremental Cadena continues the line of work by Garlan et. al. on model-checking pub/sub systems n n model-checkers that support OO structures directly make it much easier to model such systems basing model-checker scheduling on scheduling policy of actual system dramatically reduces state-space
Future Work… n Focus on using static analysis techniques to check other properties n n Building model-checking infrastructure dedicated to CORBA-like distributed systems n n flexible scheduling, flexible inclusion of dedicated models of middleware services (e. g. , data service) Refinement checking n n n escape/confinement analysis checking that code conforms to component behavior specs (cf. Microsoft Research BEHAVE project) modify IDL code generation process to include “cookie-crumbs” that make it easier for analysis tools to check code conformance Case studies with Boeing and Rockwell-Collins
Project Web Site http: //www. cis. ksu. edu/cadena
Скачать презентацию Cadena An Integrated Environment for Developing High-Assurance Component-based
c45b8e4895cb296922325d43454305c4.ppt