1ni.com

ni.com

ni.com

Spaghetti and Shared Variables

Jordan McBain, Ph.D., CLA

Dynamic Reactor Pattern for Distributed Systems in Control and Monitoring

4ni.com

Brose North America, Inc.Mechatronic Systems and Drives for Automobiles

Structures and components for vehicle seats

Systems for engine cooling,

electric motors and drives

Modules and

components

for vehicle doors

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”

6ni.com

Shared Variables

NI’s perspective

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

8ni.com

Object-Oriented ParadigmThe 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)

9ni.com

Object-Oriented ParadigmInheritance & 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

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_1Geez. 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?

11ni.com

Error

HandlingLogging Channel

ManagerBroadcaster Process A

CRIO1

Error

HandlingLogging Channel

ManagerBroadcaster Process B

CRIO2

GUI

Broadcaster

Central

Error

HandlingCentral

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!

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:

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

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

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!

16ni.com

Problem Abstraction: Design PatternBroadcaster

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

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

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

19ni.com

Participants

• Passes data between services depending on registration

• Network and Concurrency Abstraction Layer

Published Variable Broadcaster

Broadcaster

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

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

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

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

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

25ni.com

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:

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

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

29ni.com

Conclusions

30ni.com