1 / 62

Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems

Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems. SAnToS Laboratory, Kansas State University, USA. http://www.cis.ksu.edu/cadena. Principal Investigators. Postdocs and Students. Radu Iosif Hongjun Zheng Corina Pasareanu Georg Jung. Robby

nora-meyers
Download Presentation

Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cadena:An Integrated Environment for Developing High-Assurance Component-based Systems SAnToS Laboratory, Kansas State University, USA http://www.cis.ksu.edu/cadena Principal Investigators Postdocs and Students Radu Iosif Hongjun Zheng Corina Pasareanu Georg Jung Robby Venkatesh Ranganath Oksana Tkachuk William Deng Matt Dwyer John Hatcliff 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. Conclusions • Software is moving rapidly towards distributed, component-based systems • Since concurrent/distributed systems are difficult to reason about, we would like to apply model-checking, static-analyses, and other formal methods • To make this feasible, one needs multiple layers of abstraction (modern systems are huge!) • Interface Definition Languages (e.g., CORBA IDL) provide an excellent hook for attaching light-weight formal specifications • Model-checking modern software (heavily OO) requires using a tool like dSpin

  3. Analysis & Verification of Fighter Aircraft Mission Control Systems • Mission-control software for Boeing military aircraft, e.g., F-18 E/F, Harrier, UCAV • Boeing’s Bold Stroke Avionics Middleware • CORBA event-based systems • Focus is developing a rigorous design process with formal design artifacts that can be automatically checked for common design flaws

  4. 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

  5. Software Infrastructure • Programmed using a component-based Real-Time CORBA framework • CORBA is middleware • rich infrastructure for building heterogeneous object-oriented distributed systems • Components communicate by • publishing/subscribing to events • making method calls on component interfaces • Loose coupling addresses a number of issues • easier to reuse components, distribution of resources on aircraft, easy to incorporate real-time aspects, easier to have disjoint groups of developers

  6. Control-Push Data-Pull dataAvailable getData() dataAvailable getData() Configuration Run-time Actions Bisubscribe to a dataAvailable event published by A A publishes a dataAvailable event Biconnect to an interface of A that provides a getData() method 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

  7. Control-Push Data-Pull Structure 4 4 1. Logical GPS component receives a periodic event indicating that it should read the physical GPS device. 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

  8. Larger Configuration …moving up to 1000+ components

  9. System Requirements Output Requirements • The system shall disable the display of steering information when deselected by the pilot. • When the navigation steering mode is selected, the system shall: • Update navigation steering information display outputs at 20Hz rate based on current airframe data and the current list of navigation points that have been submitted by the navigator. The latency between the GPS data inputs and the display output shall be less than a single 20 Hz frame. The latency between navigation point input and the associated output shall be less than a single 5 Hz frame. • When the tactical steering mode is selected, the system shall: • Update tactical steering information display outputs whenever the airframe position data changes. • The system shall display new aircraft position data at a 20 Hz rate. The latency between associated inputs and this output shall be less than a single 20 Hz frame. Very idealized(!), but should give you the flavor Input Requirements • The system shall request new inputs from the GPS subsystem at a 40 Hz rate. • The system shall poll for a pilot steering mode input at a 1 Hz rate. • The system shall receive data from the navigator controls at a 5 Hz rate.

  10. System Design Aspects Outputs required @ different rates Inputs triggered @ different rates Intermediate components correlate incoming data and produce higher-level info Sensor1 60Hz 20Hz Display Sensor1 AirFrame 1Hz 1Hz Mode Switch Control 20Hz Sensor1 20Hz Display 5Hz Sensor1 Implement mode semantics for changing subsystem behavior Map components to onboard network nodes Declare rates/priorities for intermediate event handlers Off

  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

  12. Current Challenges • Systems with 1000+ components • Development team of 100+ developers • Process moves directly from informal textual requirements documents to C++ coding (!) • UML artifacts (e.g., collaboration diagrams) are usually produced only as documentation • not automatically analyzed • not leveraged in any way to e.g., generate configuration information • usually show partial descriptions and are not maintained • Still resistance by “legacy developers” to higher-level descriptions • moving away from machine code has been difficult for some developers

  13. 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 realistic systems • Must propose solutions that fit within current development process • Must propose metrics for tool performance and ease of use • evaluation by Boeing research team • Must make significant progress in one year with regular evaluation milestones

  14. Next… Short-comings in Bold Stroke development that we will attempt to address

  15. Lack of Modeling C++ component library development Informal natural language requirements <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> XML configurator information • Current development includes little high-level modeling • Design errors appear late in development cycle and correction is more costly • what are the ramifications of switching from lazy-active to eager-active components? • what are the ramifications of distributing components to different boards?

  16. Unleveraged Artifacts • Current design/model artifacts are used as informal documentation • not connected to analysis/visualization tools • not connected to configuration generation • not connected to code generation

  17. 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 …also mode-aware dependences

  18. 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!

  19. No Unifying Mechanism ? C++ Component Code UML 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

  20. Cadena Cadena CCM Interface Definition Language Java/C++ Component Code TAO Extensions 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

  21. Example System

  22. Component Ports event sink 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 }

  23. 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 } event source

  24. 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 } data source (facet)

  25. Component Code Generation Using CCM IDL Compiler Completely auto-generated code templates + component logic component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } User only fills in body of methods for event-handlers, interfaces Currently in Bold Stroke 8-12 classes drawn by hand in Rational Rose, then code templates generated from this (component structure must be re-specified each time). = Push() GetData() tacticalSteering : BM__ModalComponent Push() GetData()

  26. Cadena Component Assembly abstract distribution nodes 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 } …

  27. 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 } … rate group declaration

  28. 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

  29. 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 } …

  30. 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 } …

  31. 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 DeviceComponent called GPS

  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 } … connect event INPUT port of current component to event OUTPUT port of EventChannel

  33. Cadena Component Assembly

  34. Cadena Visualization

  35. Glue Code Generation Cadena “Glue Code” Generation Glue Code Execution gives allocation and deployment of component instances and connections(complete system) Current Boeing Glue Code Generation <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> Bold Stroke XML Configurator Info Glue Code

  36. Code Generation Summary component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } “Glue Code” Generation Glue Code Execution gives allocation and deployment of component instances and connections(complete system) Component Code Generation … BM.Device BM.LazyActive BM.Modal

  37. Assessment • We’ve done a lot of work already and none of it has to do with model-checking. • Tool building + reading CCM spec (1000+ pages!) • But… • Boeing developers now have high-level artifacts that definitely want to use (a substantial benefit) • We can now try to “sneak in” formal methods attached to these high-level artifacts • add behavioral annotations to high-level artifacts • modify code generation process to generate “cookie-crumbs” in the code that can be recognized by formal-methods tools to, e.g., help check refinement.

  38. 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

  39. 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 {} } …

  40. 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

  41. 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

  42. 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

  43. 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 mode cases

  44. 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 {} } … data flow specification

  45. 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 {} } … publish event

  46. Assessment • CCM IDL, connection information, and behavioral specification are enough to • generate precise mode-aware dependence information • generate models suitable for model-checking model-behavior • Seems natural to some one in the model-checking community • Boeing team thought writing behavior specs would be too much effort(!)

  47. Light-weight Dependency Specs triggers no other actions in enabled mode, shows actions triggered by dataIn.get_data() 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 { ... }

  48. Next… Now, on to modeling…

  49. CORBA Overview CORBA middleware Proxies and middleware take of marshalling & unmarshalling of data and moving data across communication links Interface specification for called methods (written in IDL) Java Proxies C++ Proxies C Proxies C# Proxies Interface Definition Language Functionality Distributed, heterogeneous systems C++ Java C# C

  50. Event Channel A lot going on behind the scenes… implements event correlation maintains a list of consumers GPS(event supplier) AirFrame(event consumer) Proxy Supplier Proxy Consumer Event Channel Automatically generated

More Related