Discover an object-oriented (OOP) design pattern that enables a distributed architecture to scale dynamically at run time

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”

6. 6ni.com
Shared Variables
NI’s perspective

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

29. 29ni.com
Conclusions

30. 30ni.com