1 / 59

Model Based Systems Engineering

Model Based Systems Engineering. Jonathan Sprinkle Center for Hybrid and Embedded Software Systems http://www.eecs.berkeley.edu/~sprinkle/. Overview. Nature/Nurture Motivation Methods Domain-specific modeling Generative techniques Applications (Previous/Possible) Avionics Autonomy

hali
Télécharger la présentation

Model Based Systems Engineering

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. Model BasedSystems Engineering Jonathan SprinkleCenter for Hybrid and Embedded Software Systems http://www.eecs.berkeley.edu/~sprinkle/

  2. Overview • Nature/Nurture • Motivation • Methods • Domain-specific modeling • Generative techniques • Applications (Previous/Possible) • Avionics Autonomy • Toolchain Constraints • Wrap up, & looking forward Jonathan Sprinkle, UC Berkeley

  3. Nature/Nurture • Originally from Northeast TN, Southwest VA • Graduated from Tennessee Tech, 1999 • Double major: EE, CompE (1st ever) • Earned stripes as an engineer • Graduate School at Vanderbilt University • Masters Degree, 2000 • PhD, 2003 • Learned science of formal modeling • Postdoc at UC Berkeley • Cut teeth on application problems • Executive Director of Center for Hybrid and Embedded Software Systems (Chess) • Earned perspective on “big picture” Jonathan Sprinkle, UC Berkeley

  4. These computers these days… • Embedded systems are used for many kinds of purposes and products • Fault diagnostics • Onboard/autonomous strategies • Medical devices • Sensor networks • Mobile phones • Tricky part: software is • Nontrivial • Unpredictable • Uncomposable • I and II • II and III • I, II, and III Thanks to Gabor Karsai and Janos Sztipanovits for the inspiration for this slide. Jonathan Sprinkle, UC Berkeley

  5. “Why, back when I was a budding programmer, we didn’t even have keyboards!! We had to discover our own tools! And we worked our hairy little fingers to the bone. AND WE LIKED IT!” 2001: A Space Odyssey Back when I was a kid... • Managing system level code from the code itself is an intractable problem • Too many crosscutting req’ts (power, cache, ‘correctness’) • Tight coupling between • System and (physical) environment • Language and (logical) encoding • Small changes to requirements translate into large changes to implementation (i.e., large cost) Jonathan Sprinkle, UC Berkeley

  6. Create model of the system Perform Analysis Architecture exploration Simulation Generate Configuration Code Executables From the same models! Application Application Domain Evolution App. App. App. 1 2 3 DS Modeling Environment Model Builder Model Interpretation Models Model Interpreters Proposed solution: Domain-Specific Models! Example Domains & Environments: - VLSI Layout (e.g., Altera) - Engg Drawing (e.g., AutoCAD) - Physical Modeling (e.g., SolidWorks) - Signal Processing (e.g., LabVIEW) - Controls (e.g., Simulink) Jonathan Sprinkle, UC Berkeley

  7. Unrestricted Implementation Domain-Specific Design: An abstract view Domain Concepts Jonathan Sprinkle, UC Berkeley

  8. Domain-Specific Design: An abstract view Domain Concepts Defns of Domain Assumptions and Givens Jonathan Sprinkle, UC Berkeley

  9. Domain-Specific Code Generators DS CodeGenerator Domain “Instance” Jonathan Sprinkle, UC Berkeley

  10. Domain-Specific Design: Analysis Advantages: • Infer execution structure from domain assumptions • Reduce implementation-layer design/input errors • Keep implementation details flexible • Check design constraints during design • Restrict User’s Implementation Space Disadvantages: • Learning curve for design environment • Time to build design environment • Re-use cost DS CodeGenerator Domain “Instance” Jonathan Sprinkle, UC Berkeley

  11. Closing the loop: Metamodels Application Metamodeling Environment Application Domain Environment Evolution Evolution App. App. App. Formal Specifications 1 2 3 DS Modeling Environment Model Builder Model Meta-Level Interpretation Translation Models Model Interpreters Jonathan Sprinkle, UC Berkeley

  12. Metamodels • Allows: • Rapid creation of Modeling Environment • Formal structure of Model Builder • Strong typing and constraint checking • Automatic Modeling Environment Generation • Advantages: • Definition of metamodel strongly reflects system domain • Language can be visually defined and implemented • Documentation is the metamodel • End results: • System design can be managed by domain experts, not software experts • Complex interdependencies checked through structural analysis, not enforced through style guides or memoranda Jonathan Sprinkle, UC Berkeley

  13. Metamodel: Hierarchical Finite State Machines Structure—meta Sequence—meta Structure—Instance Sequence—Instance Jonathan Sprinkle, UC Berkeley

  14. Execution Semantics • While Event ei, and in State, sc • After, ei.delay, and in State, sc, • Stop clock • If exists Transition te: (src=sc, dst=sn), set sc= sn • Else if sc.parent=null, set ei = ei.amSrc.sequence.dst • Else transition through sc.parent • Advance clock Jonathan Sprinkle, UC Berkeley

  15. Modeling example: HFSM Jonathan Sprinkle, UC Berkeley

  16. Power of Modeling: Example Jonathan Sprinkle, UC Berkeley

  17. Power of Modeling: Example Jonathan Sprinkle, UC Berkeley

  18. Generative Techniques Using the structure of the model, transform domain objects into executable objects, or into other transformable objects. Decide which static domain concepts, structural simplifications, requirements/constraints can be globally or locally determined during transformation, rather than during design. Jonathan Sprinkle, UC Berkeley

  19. Map to code, implement Assembler Map to code, implement Code Generate,Add bodies Map to UML Software Model No map! Generate callsto components DomainModel Components Domain-specific modeling w/ Generative Techniques AbstractModel ExecutableModel Solve problem in domain terms Slide created by Juha Pekka Tolvanen, Matti Rossi, Jonathan Sprinkle Jonathan Sprinkle, UC Berkeley

  20. M M s c L C A S M M < > = s c ; ; ; ; Modeling language: formal definition AbstractSyntax,A SemanticDomain,S Semantics ConcreteSyntax,C Thanks to Janos Sztipanovits for the inspiration of this slide. Jonathan Sprinkle, UC Berkeley

  21. Removing Detail Implementation Specificity Adding Generality Paradigm-independence “Universal” meaning Performing abstraction is… Extracting common elements into a parameterizable representation that can be used to recover the original representation, and possibly other archetypally equivalent representations. Jonathan Sprinkle, UC Berkeley

  22. Where do they all fit? Embedded Controls Applications GenerativeTechniques Domain-specific modeling Jonathan Sprinkle, UC Berkeley

  23. Applications • SEC Capstone Demonstration • Pursuit/Evasion of fixed-wing aircraft • Joint work with Dr. Mike Eklund, Dr. Jin Kim, Prof. Shankar Sastry [1] J. Mikael Eklund, Jonathan Sprinkle, S. Shankar Sastry, "Implementing and Testing a Nonlinear Model Predictive Tracking Controller for Aerial Pursuit Evasion Games on a Fixed Wing Aircraft", Proceedings of American Control Conference (ACC) 2005, 1509–1514, Portland, OR, Jun., 8–10, 2005. [2] Jonathan Sprinkle, J. Mikael Eklund, H. Jin Kim, S. Shankar Sastry, "Encoding Aerial Pursuit/Evasion Games with Fixed Wing Aircraft into a Nonlinear Model Predictive Tracking Controller", Proceedings of the 43rd IEEE Conference on Decision and Control, vol. 3, 2609–2614, Nassau, Bahamas, Dec., 14–17, 2004. Jonathan Sprinkle, UC Berkeley

  24. End , T T T ( ) ( ) b b X U B L 1 + + ¢ x x u u k k 0 0 0 k k m 1 1 m 1 Begin Aircraft Control Jonathan Sprinkle, UC Berkeley

  25. End , T T T ( ) ( ) b b X U B L 1 + + ¢ x x u u k k 0 0 0 k k m 1 1 m 1 T ( ) b b B 2 + 0 Begin m 2 2 m 2 Aircraft Control Obstacle Jonathan Sprinkle, UC Berkeley

  26. End , T T T ( ) ( ) b b X U B L 1 + + ¢ x x u u k k 0 0 0 k k m 1 1 m 1 T ( ) b b B 2 + 0 Begin m 2 2 m 2 T ( ) b b B 3 + 0 m 3 3 m 3 Aircraft Control Obstacle Boundary Jonathan Sprinkle, UC Berkeley

  27. Whatsa Matter? Are ya Chicken? End N 1 ¡ P ( ) b J L 0 x u = = k k ; ; M 1 k k : : k 0 = , T T T ( ) ( ) b b X U B L 1 + + ¢ x x u u k k 0 0 0 k k m 1 1 m 1 T ( ) b b B 2 + 0 Begin m 2 2 m 2 T ( ) b b B 3 + 0 m 3 3 m 3 T ( ) b b B 4 + 0 m ? ? m ? Aircraft Control? Obstacle Enemy… Boundary Jonathan Sprinkle, UC Berkeley

  28. 10 MinutesTime Limitation for Adversary Endpoint Ingress Win ConditionPursuer has targeted Evader Constraints/Rules Boundary for all vehicles FriendlyIngress Waypoint “Win” Point for Friendly AdversaryIngress Waypoint Jonathan Sprinkle, UC Berkeley

  29. 8 [ / ] f 5 0 1 ¡ ¡ ¡ < < s 1 u _ v < [ ] [ / ] ( ) f 5 0 5 0 1 1 6 6 ¡ ¡ s u m a p u = _ _ v v ; [ / ] f 5 0 1 : < < s u 1 _ v 1 ¡ 8 1 = [ ] ¡ ¡ 5 0 < < ¡ 1 u _ ¼ s à < 1 ¡ ( ) [ = = ] [ ] 1 1 6 6 5 0 5 0 ¡ ¡ u m a p u ¼ ¼ s _ = _ à à ; ; 1 ¡ = [ ] 5 0 1 : < < ¼ s u 1 _ à 8 [ / ] f 1 0 1 t ¡ ¡ ¡ < < s 1 u h i _ z < ( ) [ ] [ / ] f ( ( ) ) 1 0 1 0 1 1 6 6 t ¡ ¡ f D S _ _ i m a p u s u = _ _ z z ; u x e u m x u o u x m u u u = = = _ _ _ [ / ] f 1 0 1 t : < < à v z s u 1 ; ; ; _ z Game Constraints Control Input Constraints API Exposed Dynamics Abstracted DemoSim System Architecture Pursuit/EvasionLogic + Enabled by Component technology Open Source ITAR Restricted x86 Laptop, Linux RH9(perfctr-kernel 2.4) Boeing T-33 Trainer Jetca. 1953 Jonathan Sprinkle, UC Berkeley

  30. Methodology Jonathan Sprinkle, UC Berkeley

  31. Application Results: Pre-VIP Testing Jonathan Sprinkle, UC Berkeley

  32. Application Results: VIP Day Pilot comment: “Plane reacted just like pilots are trained to do” Sprinkle Translation: “I couldn’t tell whether it was a computer or person controlling plane.” Jonathan Sprinkle, UC Berkeley

  33. Applications • SEC Capstone Demonstration • Landing/Wave-off scenario (safety calculation) • Joint work with Dr. Mike Eklund, Dr. Ian Mitchell, Prof. Shankar Sastry [3] Jonathan Sprinkle, Aaron D. Ames, J. Mikael Eklund, Ian Mitchell, S. Shankar Sastry, "Online Safety Calculations for Glideslope Recapture", Innovations in Systems and Software Engineering, vol. 1, no. 2, pp. 157–175 , Sep. 2005. [4] Jonathan Sprinkle, J. Mikael Eklund, S. Shankar Sastry, "Deciding to Land a UAV Safely in Real Time", Proceedings of American Control Conference (ACC) 2005, 3506–3511, Portland, OR, Jun. 8–10, 2005. Jonathan Sprinkle, UC Berkeley

  34. Landing Scenario • Consider a fixed-wing UAV following its glideslope Jonathan Sprinkle, UC Berkeley

  35. Motivating Example • It is directed off its landing path Jonathan Sprinkle, UC Berkeley

  36. Motivating Example • And after some time redirected to land Can the decision to safely land: - be made in real time? - be guaranteed as true? Jonathan Sprinkle, UC Berkeley

  37. x x x Engineering Problems • Answering “in time” Now timesteps Question asked Jonathan Sprinkle, UC Berkeley

  38. x x x Engineering Problems Now timesteps Question asked Jonathan Sprinkle, UC Berkeley

  39. x x x Engineering Problems Now timesteps Question asked Jonathan Sprinkle, UC Berkeley

  40. Validation Interval x x x i.e., you should use the validation interval to ask about the time at which you would actually be able to do something Engineering Problems Computation Interval Now timesteps Question asked Answer given Action will be taken The computation interval should influence the state data used for the calculation (derived from validation interval) Jonathan Sprinkle, UC Berkeley

  41. Technology and Analysis Solutions for Reachability • Forward: • Must be recomputed for each start point • Backward: • Must be recomputed for each end point • Both dimensionally exponential • 5 dimen: ~hours to compute • 6 dimen: ~weeks Figures by Ian Mitchell Jonathan Sprinkle, UC Berkeley

  42. Implementation and Results Initial Runway Jonathan Sprinkle, UC Berkeley

  43. Implementation and Results All pieces fit together, step size changes by power of 10 to match required resolution [0,3) [3,10) Jonathan Sprinkle, UC Berkeley

  44. Implementation and Results [1,3) All pieces fit together, step size changes by power of 10 to match required resolution [3,10) [0,1) Jonathan Sprinkle, UC Berkeley

  45. 0 1 _ ~ T ( ) x f ~ 1 p x u ; ( ) H ~ i 8 [ ± ± ] x p m n µ 2 8 5 3 1 5 = ( ( ) ) _ 2 f µ µ K ; ( ) x G f ~ x x x x 3 = U 1 3 1 3 2 x : ; : ; @ A u ; ; ; > ; ; x 1 > _ > µ [ ± ± ] Ã 0 2 0 2 ¡ + > 2 G > : ; : ; > < [ ] f G 1 0 0 1 0 0 t ¡ + 2 x = 2 0 ; ; > [ ] f 1 5 1 5 t #define #define #include ... ¡ + > 2 x 3 > ; ; > > #define #define #include ... > 0 : x = 1 #define #define #include ... 010010110111100101101 0001010 1101010 0011111 010010110111100101101 0001010 1101010 0011111 010010110111100101101 0001010 1101010 0011111 Generative Strategy Reach-Set Generator Decision Controller Generator Testbed Deployment Compilation/Linking onlinequery real-timeresult Jonathan Sprinkle, UC Berkeley

  46. Analysis • Safety of ground and vehicle increased • reduced stress and decision load for pilot • aircraft training less of a factor than before • hyper-accurate safe set calculations • Design lends itself to multiple aircraft • simply create new sets based on constraints • no increase in computation (simple lookup) • uniform integration strategy • Level of autonomy increased • multiple sets for different scenarios (hazardous weather, wartime, etc.) • guaranteed within operational parameters Jonathan Sprinkle, UC Berkeley

  47. Center for Hybrid andEmbedded Software Systems Exploration Construction Simulation Verification Generation Platform Modeling Agenda: Toolchain Support Jonathan Sprinkle, UC Berkeley

  48. Conclusions • Applications of Embedded Systems are cool! • Complexity and interconnectedness require theoretical understanding in order to succeed • Only with high-confidence systems can autonomous, assistive, and x-by-wire systems be deployed in society • Through model-based design, high-confidence systems can be built by domain experts Jonathan Sprinkle, UC Berkeley

  49. More Reading [1] J. Mikael Eklund, Jonathan Sprinkle, S. Shankar Sastry, "Implementing and Testing a Nonlinear Model Predictive Tracking Controller for Aerial Pursuit Evasion Games on a Fixed Wing Aircraft", Proceedings of American Control Conference (ACC) 2005, 1509–1514, Portland, OR, Jun. 8–10, 2005. [2] Jonathan Sprinkle, J. Mikael Eklund, H. Jin Kim, S. Shankar Sastry, "Encoding Aerial Pursuit/Evasion Games with Fixed Wing Aircraft into a Nonlinear Model Predictive Tracking Controller", Proceedings of the 43rd IEEE Conference on Decision and Control, vol. 3, 2609–2614, Nassau, Bahamas, Dec. 14–17, 2004. [3] Jonathan Sprinkle, Aaron D. Ames, J. Mikael Eklund, Ian Mitchell, S. Shankar Sastry, "Online Safety Calculations for Glideslope Recapture", Innovations in Systems and Software Engineering, vol. 1, no. 2, pp. 157–175 , Sep. 2005. [4] Jonathan Sprinkle, J. Mikael Eklund, S. Shankar Sastry, "Deciding to Land a UAV Safely in Real Time", Proceedings of American Control Conference (ACC) 2005, 3506–3511, Portland, OR, Jun. 8–10, 2005. [5] Jonathan Sprinkle, "Model-Integrated Computing", IEEE Potentials, vol. 23, no. 1, pp. 28–30, Feb. 2004. [6] Jonathan Sprinkle, "Generative Components for Hybrid Systems Tools", J. of Obj. Tech., vol. 4, no. 3, pp. 35–40, Apr. 2005. Jonathan Sprinkle, UC Berkeley

  50. Thanks! http://www.eecs.berkeley.edu/~sprinkle/ http://sprinkletoday.com/ sprinkle@EECS.Berkeley.Edu sprinkle@IEEE.org sprinkle@acm.org Jonathan Sprinkle, UC Berkeley

More Related