Dynamic Reactor Pattern for Distributed Systems in Control and Monitoring
Download as PPTX, PDF2 likes234 views
The document discusses the dynamic reactor pattern for distributed systems and its application in control and monitoring, outlining problems with shared variables and the need for service-oriented architectures. It presents design considerations for object-oriented paradigms in large-scale applications, emphasizes error handling, and suggests a broadcaster service to manage communication between services. Future directions include message prioritization, integration with various network types, and enhancements to the messaging scheme.
![8ni.com
Object-Oriented Paradigm
The Class
Class – “software module”
◦ A rigid interface specification
◦ Encapsulation
◦ Information Hiding
DataA: uint32
DataB: UserClass
[A,B]=MyFunc1(uint32, bool, dbl)
[E]=MyFunc2(bool, classA)
Class A
“struct”
Or cluster
Acces
Routines
(bunch o’
VI’s)](https://image.slidesharecdn.com/ts6157mcbain-160203013658/85/Dynamic-Reactor-Pattern-for-Distributed-Systems-in-Control-and-Monitoring-8-320.jpg)
![9ni.com
Object-Oriented Paradigm
Inheritance & Polymorphism
DataA: uint32
DataB: UserClass
Data:bool
Data1: int32
[A,B]=MyFunc1(uint32, bool, dbl)
[E]=MyFunc2(bool, classA)
[A]=MyFunc3(bool, dbl)
[E]=MyFunc4(bool, dbl)
Class D
Data: bool
[A]=MyFunc3(bool, dbl)
Class B
Data1: int32
DataA: uint32
DataB: UserClass
[E]=MyFunc4(bool, dbl)
[A,B]=MyFunc1(uint32, bool, dbl)
[E]=MyFunc2(bool, classA)
Class C
DataA: uint32
DataB: UserClass
[A,B]=MyFunc1(uint32, bool, dbl)
[E]=MyFunc2(bool, classA)
Class A
Multiple
Inheritance
Not Supported
In LabVIEW](https://image.slidesharecdn.com/ts6157mcbain-160203013658/85/Dynamic-Reactor-Pattern-for-Distributed-Systems-in-Control-and-Monitoring-9-320.jpg)
![12ni.com
Reactor Pattern
• Application should only block on a single
source of events
• Avoid context switching and synchronization
• Adding new services and published
variables should be easy
• Shield application code from complexity of
multi-threading & synchronization
[POSA2, 1999]
Four forces:](https://image.slidesharecdn.com/ts6157mcbain-160203013658/85/Dynamic-Reactor-Pattern-for-Distributed-Systems-in-Control-and-Monitoring-12-320.jpg)
![13ni.com
Reactor Pattern
• Synchronously wait on events from multiple sources
• Integrate demultiplexing and dispatching events to processing services
• Decouple event demultiplexing/dispatching from application-specific
processing
[POSA2, 1999]
Solution](https://image.slidesharecdn.com/ts6157mcbain-160203013658/85/Dynamic-Reactor-Pattern-for-Distributed-Systems-in-Control-and-Monitoring-13-320.jpg)
Dynamic Reactor Pattern for Distributed Systems in Control and Monitoring
- 1. 1ni.com
- 2. ni.com
- 3. ni.com Spaghetti and Shared Variables Jordan McBain, Ph.D., CLA Dynamic Reactor Pattern for Distributed Systems in Control and Monitoring
- 4. 4ni.com Brose North America, Inc. Mechatronic Systems and Drives forAutomobiles Structures and components for vehicle seats Systems for engine cooling, electric motors and drives Modules and components for vehicle doors
- 5. 5ni.com Spaghetti and Shared Variables • Shared Variables are great for their designed use case, BUT • Typical usage leads to “Spaghetti and Shared Variables” • Building a large scale application needs more o Service Oriented Architectures o Open Standards (e.g. MIMOSA) • Object Oriented Design Pattern • Dynamic “Reactor Pattern” for LabVIEW • Queue, FIFO, etc. instead of “pointers” to callbacks • Online subscription to “published variables” • Dynamic online creation of “published variables”
- 7. 7ni.com Design Iterations • Presented at South-East Michigan User Group Meeting (Dec 2014) • Very rough sketch • Deficiencies: o Strings to help identify published variables – Inefficient string comparisons o Static published variable creation/destruction – Or at least introducing potential for blocking o Not ready for large scale application o No consideration given to streaming • Today’s presentation resolves most of these issues
- 8. 8ni.com Object-Oriented Paradigm The Class Class – “software module” ◦ A rigid interface specification ◦ Encapsulation ◦ Information Hiding DataA: uint32 DataB: UserClass [A,B]=MyFunc1(uint32, bool, dbl) [E]=MyFunc2(bool, classA) Class A “struct” Or cluster Acces Routines (bunch o’ VI’s)
- 9. 9ni.com Object-Oriented Paradigm Inheritance & Polymorphism DataA: uint32 DataB: UserClass Data:bool Data1: int32 [A,B]=MyFunc1(uint32, bool, dbl) [E]=MyFunc2(bool, classA) [A]=MyFunc3(bool, dbl) [E]=MyFunc4(bool, dbl) Class D Data: bool [A]=MyFunc3(bool, dbl) Class B Data1: int32 DataA: uint32 DataB: UserClass [E]=MyFunc4(bool, dbl) [A,B]=MyFunc1(uint32, bool, dbl) [E]=MyFunc2(bool, classA) Class C DataA: uint32 DataB: UserClass [A,B]=MyFunc1(uint32, bool, dbl) [E]=MyFunc2(bool, classA) Class A Multiple Inheritance Not Supported In LabVIEW
- 10. 10ni.com Multi-Threaded Environment Central Error Handling Publish: - Error State - Error Event Logging Publish: - Logged Channel IDs - Logging Rate Channel Manager Publish: - Channel IDs - Available Algorithms - Available Libraries BroadcasterProcess A Publish: - Process A_1 - Process A_2 Can I log error events? Please!? User Interface Also I’d like to know about Process A_1 Geez. I’d like to know about available algorithms Reuse note: Libraries Publish algorithms Also, tell me about error states! I’d like to tell the Channel manager to add an algorithm too Publish: - Run State What is the run state? May I assist coordination?
- 11. 11ni.com Error Handling Logging Channel Manager Broadcaster Process A CRIO1 Error Handling Logging Channel Manager Broadcaster Process B CRIO2 GUI Broadcaster Central Error Handling Central Logging GUI Hello, CRIO1 here! Anyone out there? Yup! CRIO 2 here! CRIO1 &CRIO2, I’m the GUI! I want to be everyone’s boss! No way! We don’t need servers. Let’s just be peers!
- 12. 12ni.com Reactor Pattern • Application should only block on a single source of events • Avoid context switching and synchronization • Adding new services and published variables should be easy • Shield application code from complexity of multi-threading & synchronization [POSA2, 1999] Four forces:
- 13. 13ni.com Reactor Pattern • Synchronously wait on events from multiple sources • Integrate demultiplexing and dispatching events to processing services • Decouple event demultiplexing/dispatching from application-specific processing [POSA2, 1999] Solution
- 14. 14ni.com Reactor Pattern • Reactor class allows registration & removal of event handlers • Reactor waits on a group of operating system mechanisms • E.g. Files, sockets, etc. • When OS mechanism triggers Reactor, the Reactor • Looks up event handlers registered for that event • Calls the handler’s call back via a “pointer” to the handler o In LabVIEW a Data Value Reference • Nice pattern for single threaded applications BUT for parallel apps: Implementation Limitations • Race Conditions • Deadlock • Non-preemptive • Debugging
- 15. 15ni.com Design Problem • In a multi-threaded environment, threads may: • Have data other threads want • Want to know data from other threads • In a distributed environment, distributed threads may: • Have data other distributed threads want • Want to know data from other distributed threads The same problem! Possibly occurring at the same time! Reuse Potential!
- 16. 16ni.com Problem Abstraction: Design Pattern Broadcaster Service Hi, I am a service named <????> I will have variables I want to publish throughout my life time I will want to subscribe and unsubscribe to other variables during my life time Send me updates about other variables via this COM scheme Ok. No Problem. Tell me what you want to know about via this COM scheme Service Service Network Broadcaster Service Service Service Let’s abstract network (EtherNet, CAN, etc.) details for our services
- 17. 17ni.com Participants • Data storage class • Applications will create new ones to handle individual needs • Must be registered to an aggregator to be of any use • When aggregator is registered to broadcaster: o Services can subscribe to receive information feeds o Services can request to write to published variables PublishedVariable
- 18. 18ni.com Participants • Stores (“Aggregates”) Published Variables • When a variable is updated, transmits to Broadcaster for dispersion o Only transmits to Broadcaster with active subscriptions • Service class inherits this o So it can be both an Aggregator and a subscriber Published Variable Aggregator
- 19. 19ni.com Participants • Passes data between services depending on registration • Network and Concurrency Abstraction Layer Published Variable Broadcaster Broadcaster
- 20. 20ni.com Participants • Inherits Published Variable Broadcaster • Interface hides COM scheme (e.g. queue) • Transmits command objects to actual Broadcaster for processing • COM Scheme transmits each operation’s parameters to only Broadcaster • Inversion of control • Each command object: o Has a “Receiver” access routine that is friended to Broadcaster • When Broadcaster receives object: o Calls this “Receiver” and passes itself to the “Receiver” o The Receiver calls the appropriate method in Broadcaster to get the work done Distributed Published Variable Broadcaster Broadcaster
- 21. 21ni.com Participants • PV Aggregator • Hidden inside Broadcaster’s “Run Routine” • Sends UDP multicast message announcing presence • Has a published variable acting as a queue for newly discovered IP’s PV Broadcaster: Multicaster
- 22. 22ni.com Participants • Service (Subscriber + Aggregator) • Subscribes to Multicaster’s “Discovered IP” PV • Attempts to setup communication, if successful: • Publishes this as “Registered IP” PV o Multicaster subscribed • Asynchronously launches an aggregator to represent all aggregator’s on the distributed computer o Think: Actor Framework • Design Decision: Polls all “Registered IP’s” via TCP • Makes local subscriptions for “Registered IP’s” and transmit via TCP PV Broadcaster: Network Facade
- 23. 23ni.com Participants • Abstracts the communication transmission/reception mechanism • Choice of actual mechanism initialized on “Init()” • Otherwise interface between child classes is the same • Options • User Events • Queues • FIFO’s • Actor Framework “Queues”? COM Scheme
- 24. 24ni.com Participants • Objective for threads to block only on one source o Must generalize the data type transmitted via communication scheme • Child classes o Broadcaster Configuration Settings – Published Variables o Aggregator Configuration Settings • Configuration Settings o Permits registration/deregistration of services and published variables – Via communication scheme hidden behind interface COM Element
- 25. 25ni.com
- 26. 26ni.com Inversion of Control • “The Hollywood Principle” • Don’t Call Us, We Will Call You • Like the Actor Framework • Opportunity to use “Friends” and “Community Scope” in LabVIEW • Communication Elements have method for Broadcaster & Aggregator • Once called, they choose appropriate Method in Broadcaster/Aggregator • Avoid if/thens and avoid BAD code:
- 27. 27ni.com Re-Use Potential • Reuse between projects • Reuse within the same project • Example: Recursive use of “Aggregator Concept” • Make “Channel Manager” an aggregator o Channels in channel manager are also aggregators o Channel manager runs in single thread of excecution o Change messaging scheme to array based scheme
- 28. 28ni.com Future • Message priorities • Urgent messages • Bit masked numeric id for VarID • Aggr Details: Allow recursive AggrID • Integration with Actor Framework • Other Network Types • CANopen, EtherCAT, etc. • Streaming Bit 0Bit NBit N+m VarIDAggr IDBroadCasterID Aggr Details Bit N+m+o
- 30. 30ni.com
Editor's Notes
- #5: 4