1 / 49

WP1: CORBA Control Systems

WP1: CORBA Control Systems. Karl-Erik Årzén & Ricardo Sanz. Main Activities and Achievements. Domain-analysis of CORBA Control Systems completed D1.1 accepted Domain architectures for CORBA Control Systems CORBA control design patterns D1.2 final version, pending approval

rearls
Download Presentation

WP1: CORBA Control 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. WP1: CORBA Control Systems Karl-Erik Årzén & Ricardo Sanz HRTC Final Review, Lund 16 September, 2003

  2. Main Activities and Achievements • Domain-analysis of CORBA Control Systems completed • D1.1 accepted • Domain architectures for CORBA Control Systems • CORBA control design patterns • D1.2 final version, pending approval • CORBA Control System Engineering Handbook • D1.3 to be sent at the end of the project Final Review, Lund, 16 September, 2003

  3. Main Activities and Achievements • Simulation tools for CORBA-based networked control loops: • TrueTime simulation toolbox extended • Switched Ethernet • Multiple Ethernets • Extra deliverable on TrueTime/Jitterbug for CORBA (HRTC057) will be completed and updated (sent at the end of the project) Final Review, Lund, 16 September, 2003

  4. Domain Analysis Deliverable 1.1 HRTC Final Review, Lund 16 September, 2003

  5. D1.1 Domain Analysis of CORBA Control Systems • Introduction • Distributed Objects and CORBA • CORBA • RT-CORBA • Competing Technologies • What is needed for HRT CORBA? • Components in Control Systems • Domain desctiptions • CORBA and component examples • CORBA Control Loops • Loop Timing • Effects of delays • TrueTime and Jitterbug for analysis and simulation Final Review, Lund, 16 September, 2003

  6. MIS Strategic Control Optimization Tactical Control Plan execution Operational Control Reactivity Advanced Control User Interface Complex Loops Conventional Process Control Simple Loops Sensors & Actuators Plant CORBA in Control Systems • CORBA: • well-suited • concept proved in other projects Final Review, Lund, 16 September, 2003

  7. HRTC Focus MIS Strategic Control Optimization • The aim of HRTC • where the hard r-t constraints are found Tactical Control Plan execution Operational Control Reactivity Advanced Control User Interface Complex Loops Conventional Process Control Simple Loops Sensors & Actuators Plant Final Review, Lund, 16 September, 2003

  8. What do we mean by ”Hard” Real-Time? • Minimum requirement: • Maximum bound on network end-to-end latency • It is assumed that the RT-CORBA technology used is able provide the corresponding guarantees on the client and server sides • Additional requirements: • Minimum bound on the network latency • Minimum jitter on the network latency Final Review, Lund, 16 September, 2003

  9. Are Control Systems Hard of Soft? • Depends on application. • Most control systems are relatively robust against delays and jitter. • For safety-critical systems the hard real-time model has many advantages • Verification • Time-triggered approaches that minimizes jitter are well suited, e.g., TTA/TTP • Most “hard” real-time control applications are not safety-critical • Less deterministic approaches work well, e.g., event-triggered implementation methods that only give upper bounds on latency • E.g., in automation and robotics Final Review, Lund, 16 September, 2003

  10. HRT-CORBA General Requirements • Deterministic Transports • IIOP one of the main sources of nondeterminism in CORBA/RT-CORBA • Different applications need different levels of determinism • Periodic requests • Sender – Reciever model • IDL support for representing periodic requests • information that concerns both the client and the server object as a single entity • associate timing attributes to this entity, e.g., the period, the amount of data that will transferred, and what the maximum allowed communication latency is • RT-CORBA activities not enough Final Review, Lund, 16 September, 2003

  11. HRT-CORBA General Requirements • Scheduling support • Network is a shared resource that needs scheduled access • Also applies to client and server-side computations if a time-triggered approach is adopted • Scheduling of distributable threads (RT-CORBA 2.0 specification) a possible solution • Global location for scheduling information • Implemented as CORBA service or as a special CORBA object • The scheduling support in RT-CORBA not enough • Small footprint • Hard real-time often needed in embedded systems with limited resources • HRT-CORBA ought to build upon Minimum CORBA rather than RT-CORBA Final Review, Lund, 16 September, 2003

  12. HRT-CORBA General Requirements • Deadlines • Deadline-based representations more natural than priority-based for many hard real-time applications • RT-CORBA 2.0 specification Final Review, Lund, 16 September, 2003

  13. HRT CORBA threats • Industrial control systems are in general based on Microsoft technologies • COM/DCOM/.NET/OPC technologies are strongly favoured • CORBA is by many considered as a too complex technology for embedded applications Final Review, Lund, 16 September, 2003

  14. Clarification from Midterm Review • How is the control-related timing issues reflected in HRT CORBA? • Timestamped messages • Described in D 2.2 • Not tested yet Final Review, Lund, 16 September, 2003

  15. Domain Architectures Deliverable 1.2 HRTC Final Review, Lund 16 September, 2003

  16. The Process of Desing • Modern control systems are very complex applications that pose special difficulties to systems designers • Design knowleddge transfer is difficult at the architectural level • Recurring designs are common in the field of automatic control but in most cases their documentation formats are restricted to small subfields of application • Control systems designs are heterogeneous and multidisciplinary by nature Final Review, Lund, 16 September, 2003

  17. Views on Architecture • Documenting domain architectures • Domain Specific Software Architectures • Technical Architectures • Frameworks • Patterns • Design patterns are the selected alternative for D1.2 Final Review, Lund, 16 September, 2003

  18. Patterns and Schemata • In this report we propose a pattern schema with two particular properties: • it specifically deals with some issues very relevant to control designers • it is generic enough to gather under the same umbrella an heterogeneous collection of patterns ranging from basic, elementary control and/or software components to plant-wide systems. • This schema is being used in the implementation of a pattern language for the construction of control systems. Final Review, Lund, 16 September, 2003

  19. What are design patterns? • Established ways of solving design problems • Distilled know-how of previous work • Documented in usable formats (pattern schemas) • Organised in pattern languages • Can be composed • Examples in all engineering field: • Chemical: Distillation Unit • Civil: Suspension Bridge • Aeronautic: Triplane Final Review, Lund, 16 September, 2003

  20. Cascade Control Yref PID 1 Yref U PID 2 U Y Y A/D A/D Final Review, Lund, 16 September, 2003

  21. Abstract Cascade Control Yref Control 1 Yref U Control-2 U Y Y A/D A/D Cascading is a design pattern Final Review, Lund, 16 September, 2003

  22. Controller Action State Controller Sensor Actuator World Final Review, Lund, 16 September, 2003

  23. Tuner Tuner Performance Parameters Controller Final Review, Lund, 16 September, 2003

  24. Tuned Controller Tuner Performance Parameters Controller Sensor Actuator Action State Final Review, Lund, 16 September, 2003

  25. Pattern Languages • Pattern languages are collections of patterns for a domain • “The sequential and organic structure of patterns for a specific application domain becomes the method for the development process” • Designs are produced by pattern combination • A pattern language can be generative Final Review, Lund, 16 September, 2003

  26. Pattern Documentation • Using a pattern schema: • Many available: GOF, Alexandrian, etc. • Domain-specific format • Typical Contents: • Name, Problem, Context, Forces, Solution, Example, etc. • CCS Pattern Schema Final Review, Lund, 16 September, 2003

  27. Name Aliases Example Problem Solution Forces Context Structure Dynamics Implementation Timing Example resolved Variants Known Uses Consequences Related with References CCS Pattern Schema Final Review, Lund, 16 September, 2003

  28. CCS Patterns • Just a first step in a pattern language for CCS • Some patterns in the document: • Active Object • Pluggable transport • Networked Control Loop Pattern • Controller Function Block Pattern • Distributed Control System Final Review, Lund, 16 September, 2003

  29. Networked Control Loop An Example HRTC Final Review, Lund 16 September, 2003

  30. Name • Networked Control Loop Final Review, Lund, 16 September, 2003

  31. Aliases • CORBA control loop • Distributed control loop Final Review, Lund, 16 September, 2003

  32. Examples • Networked control loops are becoming increasingly important in a number of application areas. • One major example is automotive systems where sensors and actuators often are located closely to the physical devices which they sense/actuate. • The control loops are closed over some data bus, e.g., CAN, TTCAN, Flexray, or TTP. • Another example is process automation where actuators and sensors often are distributed in the plant, communicating with the control system using a fieldbus, e.g. ProfiBus, Foundation, etc., Final Review, Lund, 16 September, 2003

  33. Problem • A dynamical physical system with input(s) through which one may influence it using actuator(s), and output(s) through which can measure its performance using sensor(s), has poor performance and robustness, and is negatively affected by disturbances acting on the system. • The sensors and actuators are physically separated from each other. Final Review, Lund, 16 September, 2003

  34. Solution • Increase the robustness and performance of a system through feedback control implemented in a separate controller node. • Reject disturbances acting on the systems through feedback. Final Review, Lund, 16 September, 2003

  35. Structure • Each of the three nodes support CORBA • The functionality of the three nodes is realised using CORBA objects. Controllernode Sensor node Actuator node Measurement(s) Control signal(s) Final Review, Lund, 16 September, 2003

  36. Dynamics • The dynamics of the pattern depends primarily on two things: • whether an information-push or an information-pull model is used, and • whether the interactions are one-way invocations without any return message or if they are ordinary, two-way, CORBA request-reply invocations. • In the basic, and most simple version of the pattern we assume that information-push is used both from the sensor to the controller and from the controller to the actuator. Final Review, Lund, 16 September, 2003

  37. Implementation • The pattern can be implemented using CORBA, RT-CORBA, or HRT-CORBA. The main difference between these alternatives concerns level of determinism achieved Final Review, Lund, 16 September, 2003

  38. Timing • Closing a control loop over a network gives rise to communication delays. • These delays affect the performance of the controller negatively. • From a control point of view it is desirable to have constant sampling delay and short input-output latency. • If the input-output latency is constant, it can easily be compensated for. However, it is general better to have a short latency with jitter than a longer, but constant, latency. Final Review, Lund, 16 September, 2003

  39. Engineering Handbook D 1.3 HRTC Final Review, Lund 16 September, 2003

  40. Structure • Part 1: Overview and introductory material • This part sets the stage fro what comes after. • Part 2: OMG Technology • This part describes available OMG specifications that are of relevance for the construction of CORBA-based control systems. • Part 3: CORBA Products • This part describes available products and tools that are of relevance for the construction of CORBA-based control systems. • Part 4: A Core Methodology • This part describes a basic methodology to be used in the construction of CORBA-based controllers. • Part 5: Additional Materials • This part gathers useful heterogeneous material that cannot be cleanly placed in the other parts. Final Review, Lund, 16 September, 2003

  41. Introduction Glossary CORBA RT-CORBA Embedded & Fault-tolerant UML CCM Domain Specifications ORBs Design Tools Platforms Methodological Approach Basic processes Early requirements Late requirements Architectural design Detailed design Implementation Common pitfalls Engineering for quality References Part 1: Introductory material Part 2: OMG Specifications Part 3: Software Products Part 4: Methodology Part 5: Additional Materials Appendices Final Review, Lund, 16 September, 2003

  42. Analysis and Simulation of CORBA Networked Control Loops HRTC Final Review, Lund 16 September, 2003

  43. TrueTime and Jitterbug Simulation withTrueTime Analysis withJitterbug SchedulingParameters (T,D,Prio, …) Loop TimingParameters (latencies, jitter, …) ControlPerformance (variance, rise time, overshoot, ….) Non-trivialrelationship Complex, ”nonlinear”relationship Final Review, Lund, 16 September, 2003

  44. TrueTime • Simulation of networked control loops under shared computing resources • Co-simulation of controller task execution, network transmissions, and continuous plant dynamics • Developed by Anton Cervin, Dan Henriksson, Johan Eker • Simulink-based Final Review, Lund, 16 September, 2003

  45. Computer Block • Fixed priority • EDF • Static schedule • User defined Final Review, Lund, 16 September, 2003

  46. Network Block link-layer • Switched Ethernet • Multiple networks • TCP transport added Final Review, Lund, 16 September, 2003

  47. TrueTime and CORBA • Comparative simulations of CORBA control loops • CORBA (IIOP (TCP)) – demonstrated at mid-review meeting • RT-CORBA (IIOP (TCP)) • Server-declared vs client-propagated priorities • Thread pools and thread lanes • Mutexes • HRT-CORBA • Switched Ethernet transport -- DEMO • Switch buffer size • ThrottleNet • Traffic control • TTP Transport • TDMA datalink • Simulation results relative rather than absolute Final Review, Lund, 16 September, 2003

  48. DEMO Anton Cervin Final Review, Lund, 16 September, 2003

  49. Final Review, Lund, 16 September, 2003

More Related