Analyzing Component-based Designs: The Cadena Environment

1. Analyzing Component-based Designs:The Cadena Environment SAnToS Laboratory, Kansas State University, USA http://www.cis.ksu.edu/cadena Principal Investigators Students Matt Dwyer John Hatcliff Gurdip Singh William Deng Georg Jung Adam Childs Robby Venkatesh Ranganath 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

2. Distributed Components Network

3. Distributed Components Interface Definition Language (IDL) specifications for remote methods Automatically generated proxies Java C++ C Middleware (e.g. CORBA) C Java C++

4. Distributed Components Event Service Transaction Service Component Interface Definition Language (CCM IDL) Naming Service Synchronization Service substantial portion of code auto-generated Java C++ C Middleware (e.g. CORBA) C Java C++

5. Checking CCM Systems Transaction Service Event Service Naming Service Synchronization Service Modern Software Systems Our Themes • Light-weight behavioral specifications • Leverage abstractions that programmers already write • Component IDL • Scale static analysis techniques to handle remote connections • Use emerging model-checking technology dedicated to OO structures and RT scheduling algorithms Java C++ C Middleware (e.g. CORBA) C Java C++ • These systems are huge! • What are appropriate abstractions/specifications and how can we get programmers to write them?

6. Analysis & Verification of AvionicsMission Control Systems • Mission-control software for Boeing aircraft, e.g., F-18 E/F, Harrier, UCAV • Boeing’s Bold Stroke Avionics Middleware • …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

7. Boeing Bold Stroke Platform Focus Domain Nav Sensors Weapon Management Data Links Weapons Periodic & Aperiodic Constrained Tactical Links Many Computers Mission Computer Multiple Safety Criticalities Radar Vehicle Mgmt COTS Information Security Multiple Buses O(106) Lines of Code Hard & Soft Real-Time

8. Control-Push Data-Pull dataAvailable getData() dataAvailable A publishes a dataAvailable event Bicall the getData() method of A to fetch the data Typical situation Component A computes some data that is to be read by one or more components Bi B1 A Bk Run-time Actions

9. Control-Push Data-Pull Structure 4 4 1. Logical GPS component receives a periodic event indicating that it should read the physical GPS device. Input 1 2. Logical GPS publishes DATA_AVAILABLE event 3. Airframe component fetches GPS data by calling GPS GetData method 2 4. Airframe updates its position data and publishes DATA_AVAILABLE event 3 6 5. NavDisplay component fetches AirFrame data by calling AirFrame GetData method 5 6. NavDisplay updates the physical display Output

10. Larger Configuration …moving up to 1000+ components

11. Development Process Component Integration Platform-specific Components Common Components Connect components, assign priorities, locking schemes, distribute Real Board Testing Analysis & Functional Testing Test real-time aspects, frame-overruns, etc. Debuggers, call-graph analyzers, scheduling tools Component Development 100+ developers

12. Research Context • Provided with an Open Experimental Platform (OEP) from Boeing • a sanitized version of the real system • 100,000+ lines of C++ code (including RT CORBA middleware) • 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 • evaluation by Boeing research team

13. 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”.

14. Lack of Modeling C++ component library development bypasses modeling Informal natural language requirements <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> XML component connection information • 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)

15. Unleveraged Artifacts • Current design/model artifacts are used as informal documentation • not connected to analysis/visualization tools • not connected to “glue code” (deployment code) generation

16. Lack of Model Analysis 4. All components from a particular rate group 5. Cycle checks …15-20 others related to dependencies Boeing OEP Challenge Problems 1. Forward & backward data and event dependencies 2. Dependency intersections 3. Components with high data coupling

17. 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 model-checking!

18. No Unifying Mechanism ? C++ Component Code Design Artifacts <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> High-level Specification Language Bold Stroke XML Configurator Info Integrated Development Environment Analysis and QoS Aspect Synthesis

19. Cadena Cadena CCM Interface Definition Language Java/C++ Component Code RT Aspect Specs UML Design Artifacts State Transitions System Configuration <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> High-level Specification Language Eclipse Plug-In Bold Stroke XML Configurator Info Integrated Development Environment Analysis and QoS Aspect Synthesis

20. Next… Cadena functionality and capabilities…

21. Example System

22. Example System Basic components seen earlier

23. Example System Navigation Steering Subsystem

24. Example System Tactical Steering Subsystem

25. Example System on/off on/off Display Control

26. Outline 4. Modal Behavior 1. Component Interface 2. Component Connections 3. Dependence Information

27. CCM Component Interfaces • CCM Component Interfaces are based on a notion of ports • Event ports – asynchronous event delivery • consumesport – input (event sink) • publishes port – output (event source) • Interface ports – synchronous method calls • provides port – provide interface to clients (facet) • uses port – use interface of other component (receptacle)

28. Component Ports input event port CORBA 3 CCM IDL eventtype TimeOut {} eventtype DataAvailable {} interface ReadData { readonly attribute any data; } component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut }

29. Component Ports CORBA 3 CCM IDL eventtype TimeOut {} eventtype DataAvailable {} interface ReadData { readonly attribute any data; } component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut } output event port

30. Component Ports CORBA 3 CCM IDL eventtype TimeOut {} eventtype DataAvailable {} interface ReadData { any get_data(); } component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut } provide interface to clients (facet)

31. Outline 2. Component Connections

32. Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut } instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … create instance of LazyActive component called AirFrame

33. Cadena Component Assembly connect event INPUT port of current component to event OUTPUT port of GPS component system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } …

34. Cadena Component Assembly connect data INPUT port of current component to data OUTPUT port of GPS component system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } …

35. Cadena Component Assembly

36. Cadena Visualization

37. Cadena User Interface

38. Outline 3. Dependence Information

39. Dependency Specifications • Inter-component dependences are given by connection information (already seen) • We now give notation for specifying intra-component dependencies • Light-weight specification layer that provides significant benefit … • 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

40. Light-weight Dependency Specs outDataAvailableport action call on set_data() triggers dependencydefault == none; dependencies { dataWriteOut.set_data() -> outDataAvailable; } behavior { ... }

41. Light-weight Dependency Specs triggers no other actions dependencydefault == all; dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } } behavior { ... }

42. Light-weight Dependency Specs in enabled mode, shows actions triggered by receipt of event on inDataAvailable port dependencydefault == all; dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } } behavior { ... }

43. Light-weight Dependency Specs in disabled mode, inDataAvailable triggers no other port actions dependencydefault == all; dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } } behavior { ... }

44. Outline 4. Modal Behavior

45. Transition System Semantics • Boeing engineers want to reason about system/component modes at design time • Ideal for model-checking because… • 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 as safety properties • e.g., frame-bounded response, invariants

46. Ultimate Modeling View Code Layer Check that implementations satisfy/refinement high-level specs – leverage the fact that code skeletons are automatically generated CCM IDL Model Layer Check mode behaviors, temporal properties, timing constraints Generate code, fill-in skeletons, check for refinement We don’t do all of this yet!

47. Component Behavior input ports component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes {enabled,disabled}; Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } …

48. Component Behavior component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes (enabled,disabled); Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … output ports

49. Component Behavior component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes (enabled,disabled); Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … mode declaration using CORBA IDL

50. Component Behavior component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes (enabled,disabled); Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … behavior for events on dataInReady port