alphaOCP

1
alpha-OCP

• gatech.edu

2
Outline

• Motivation
• What is the alpha-OCP
• What will it provide
• How does it relate to the beta-OCP
• When will it be available
• Reasons behind the design of the alpha-OCP
• Current Status

3

• Motivation
• ON-LINE CUSTOMIZATION / REAL-TIME ADAPTATION OF
  CONTROL ALGORITHMS
• Application Domain
• UAVs PERFORMING EXTREME MANEUVERS

4
Current System
Simulink demo of F-14 longitudinal control
5
Current gt Desired Capabilities

• What we lack
• distribution mechanism
• prioritization
• inherent support for distributed control
• ease in interacting with legacy systems
• ability to reconfigure online
• integrate without migrating all algorithms to one
  tool such as Simulink or SystemBuild

• Desired capabilities
• decoupled, mediated component communication
• control algorithms distributed across various
  processors
• ability to reconfigure system components
  dynamically
• change the quality of service of communications
  dynamically
• add new algorithms into the system at runtime
• an abstraction for specifying reconfiguration
  policies

6
Desired Setup
groundstation.gui
pilotcommand_at_groundstation.pilotstick
uav.airframe
groundstation.gui
uav.controller
q_at_uav. sensors_at_minrate20
alpha_at_uav.sensors
7
Generic Component
User Component
A
D

• A generic user component in C which maybe
  implemented as a controlshell/simulink component
• The component developer need not be concerned
  about how signals are transmitted to/from the
  component.

B
C
Input Signals
Output Signals
8
What are the Inputs and Outputs
User Component

• Inputs and Outputs could be signals or entire
  objects.
• May be represented as a tuple ltInformation, Typegt
• A ltGPS-based-altitude, doublegt
• B ltSonar-based-altitude, doublegt
• C ltVehicleModel, ModelObjectgt
• D ltFilteredAltitude, doublegt

A
D
B
C
Input Signals
Output Signals
9
What are the Inputs and Outputs
Altitude Filter
altitude_at_uav.sensors.gps
A
D
altitude_at_uav.sensors.sonar
altitude_at_filter
B
ground.models.heavemodel
C

• A altitudedouble_at_srcuav.sensors.gps_at_minrate10
  Hz_at_maxrate20Hz
• B altitudedouble_at_srcuav.sensors.sonar_at_minrate
  20Hz_at_maxrate50Hz
• C model_at_srcground.models.heavemodel_at_minrate20H
  z_at_maxrate50Hz
• D altitudedouble

10
Connections-Local Address space
Altitude Filter
A
D
B
C
Heave Model
B
A

• Primitive signals are simply provided in the
  same address space by other components running in
  the same address space
• -- No notion of distribution here

11
Connections-Distributed
Altitude Filter
A
A
D
D
B
B
C
C
A An input port (subscription in NDDS /
EventConsumer in TAO) B An input port
(subscription in NDDS / EventConsumer in TAO) C
A replica in Boldstroke D A publication in
BoldStroke
12
Connections-Distributed
Altitude Filter
A
A
D
D
B
B
C
C

• A, and B can be implemented now using the
  alpha-OCP.
• A and B can be arbitrarily reconfigured
  dynamically to read other sources of information
• C can be replicated using boldstrokes
  replication mechanism not available in the
  alpha-OCP version

13
Control Shell Integration
Altitude Filter
A
A
D
D
B
B
C
C

• Controlshell provides the ability to integrate
  raw C code and simulink components (March 2000)
• However, no distribution mechanism exists
• OCP components such as A, B, C, D will
  provide this capability

14
New code
Legacy
Altitude Filter
A
A
D
D
B
B
New Code
C
C
Altitude Filter
A
D
B
C
Functional code (legacy / new code) is thus
inherently distributable
15
What is the alpha-OCP

• C code modules
• Uses TAO to provide distributed comms
• Uses TAOs event channel for decoupled comms
• Uses TAOs CORBA implementation to allow
  distributed objects to invoke operations on each
  other -- used for setting parameters of objects
  and connecting them with other objects
• Mainly concerned with reconfiguration API rather
  than performance

16
Why TAO

• Online customization and reconfiguration requires
  objects being able to refer to each other
  during runtime
• Must be able to add components to the network
  online
• An event channel is available to provide
  decoupled communication.
• Can use IDL and CORBA to configure components
  online, just by making ORB calls.

17
What will it provide

• Decoupled, mediated component communication
• On-line QoS spec, (no scheduling)
• Late registration (dynamically add components to
  the system)
• Abstractions for specifying reconfiguration
  policies
• Heterogeneity (inherent because we use TAO)
• Usability

• Mainly, the functional aspects and API for online
  customization. For performance, we will rely on
  replication to be provide by beta-ocp.

18
a-OCP Layers

• API Wishlist
• Controls domain-specific patterns for common
  re/configuration types
• Quality of Service requirements
• Multiple levels of granularity (mission-level to
  sensor-level)
• Flexible, adaptable monitoring of signals
• Familiar block-diagram specification

19
What is reconfiguration
Physical Components
Functional
C0
C1 f(C0)
f
g
C2 g(C1)
20
API Definition - Bus Setup

• Inter-component communication using the OCP API
• Direct communication undesirable (tightly
  coupled)
• Bus component used as mediator
• Used with scheduler
• Create Scheduler
• scheduler fac.create("edu.gatech.ocp.Scheduler",
  "scheduler",400)
• scheduler.join()
• scheduler.initialize()
• scheduler.on()
• Create Bus
• bus fac.create("edu.gatech.ocp.Bus","bus",401)
• bus.join()
• bus.scheduler scheduler.name
• bus.initialize()
• bus.on()

Component (A)
Component (B)
Bus (bus)
21
API Definition - Component Setup

• Creation of component, connection to bus
• c_A fac.create("edu.gatech.mtcm3.ModeSelection",
  "c_ms",600)
• c_A.join()
• c_A.in.bus bus.name
• c_A.out.bus bus.name
• c_A.initialize()
• c_A.on()
• Event registration (for sending and receiving)
• c_A.in.qos "OCP.UAV.VehicleState"
• c_A.out.qos "OCP.UAV.PilotCommand"
• c_A.connect()

Component (A)
Component (B)
Bus (bus)
22
Component Setup

• Common API for all components that allow it to
  join and leave the network.
• A network (or virtual resource network) is
  essentially a collection of objects wired up in a
  unique way to perform a certain function

23
API Definition - Port Components

• Port components used for sending and receiving
  data
• Each port can handle multiple events
• Multiple ports allow different timeouts and
  independent setup
• Port event subscription setup
• c_A.in1.qos "OCP.UAV.SetModes"
• c_A.in2.qos "OCP.UAV.VehicleState"
• c_A.out1.qos "OCP.UAV.PilotCommand"
• c_A.out2.qos "OCP.UAV.TransitionComplete"
• c_A.connect()

Component2in/2out
24
Example Configuration
outerloop trajectoryController innerloop
singleLayerNetwork muxer controlMuxer
outerloop.inputs(state_at_uav, velocityCommand)
outerloop.outputs(mrColl, attitudeCommand)
innerloop.inputs(state, attitudeCommand)
innerloop.outputs(B1, A1, trColl)
nominalRpm.outputs(rpm) muxer.inputs(mrColl,
B1, A1, trColl, rpm) muxer.outputs(control)
25
Reconfiguration Patterns
26
Managing Dynamic Reconfiguration(work in
progress)

• Goal Maintain system integrity and consistency
• while allowing the flexibility of loose coupling.
• Approach
• Architecture-oriented global coordination
• Support standard change policies
• Unified reconfiguration process in which
• software architectural reconfiguration is
  closely
• coupled with control reconfiguration.

27
Basic Reconfiguration Actions

• Changes to Components
• Adding new components at runtime
• Deleting components
• Replacement (One-to-One)
• Changes to Connections
• Changing event subscription information at
  runtime
• Changing event priority and frequency at runtime

28
Replacement Policies

• Discrete
• Simple component replacement.
• Discrete with previous component start-up
• Instantaneous replacement, where replacement of a
  component requires information gathering or prior
  stabilization.
• Gradual
• Transitional replacement of components.
• Gradual with previous component start-up
• Transitional replacement of components with
  history/state requirements.

29
Example Discrete Replacement Policy
30
Example Discrete Replacement Policy with
Previous Start-up
31
Example Gradual Replacement Policy
Reconfiguration Agent
LLC A
Mixing/ Blending
Event Channel
t0
LLC B
LLC Low-Level Controller
32
Example Gradual Replacement Policy with Previous
Start-up
Reconfiguration Agent
LLC A
Mixing/ Blending
Event Channel
t0
LLC B (Adaptive)
Information gathering starting at t0
LLC Low-Level Controller
Transitional replacement of components with
history/state requirements.
33
How does it relate to beta-OCP
34
How does it relate to beta-OCP

• Alpha-OCP is mainly designed to investigate the
  API requirements for online customization
• Alpha-OCP flexible, dynamic, low performance
• Current-Bold stroke high performance, low
  flexibility
• Beta-OCP flexible with high performance ?

35
Evolution Path of the OpenControl Platform
Design Environments
Avionics
BoldStroke (Boeing)
Simulation
Run-Time Support
Control domain requirements communication patter
ns
High-performance services (e.g., replication)
TAO
CORBA
b-OCP
Middleware for distributed, component-based softwa
re
Real-time CORBA (from Washington University)
Real-time, dynamic reconfiguration of UAV
software (Boeing, Georgia Tech, Honeywell, UCBerke
ley)
a-OCP
Controls (Georgia Tech)
On-line customization and reconfiguration
of mid-level controls
36
Current Status
37
Scripting Example
Lookup the Virtual Resource Network and a
Factory for creating components vrn
lu("vrn") fac vrn.factory Create
Scheduler scheduler fac.create("edu.gatech.ocp.S
cheduler","scheduler",400) scheduler.join() sche
duler.on() Create a Bus for information
flow bus fac.create("edu.gatech.ocp.Bus","bus",4
01) bus.join() bus.initialize() bus.on()
Create a Mission Mode manager mms
factory.create(edu.gatech.sec.MissionModeSwitcher
,uav.mms,500) mms.initialize() mms.setModes(
Loiter,Search,Trajectory) mms.on() mms.trans
itionTo(Trajectory)
38
Before
outerloop trajectoryController innerloop
singlerLayerNetwork muxer controlMuxer
outerloop.inputs(state_at_uav, velocityCommand)
outerloop.outputs(mrColl, attitudeCommand)
innerloop.inputs(state, attitudeCommand)
innerloop.outputs(B1, A1, trColl)
nominalRpm.outputs(rpm) muxer.inputs(mrColl,
B1, A1, trColl, rpm) muxer.outputs(control)
39
During

• recon create(ReconAgent)
• rpmController create(RpmController)
• recon.add(nominalRpm,rpmController)
• recon.switchPolicy(DISCRETE)
• recon.switchTo(rpmController)

40
After
41
Prototype Demonstration
42
When will it be available

• Summer 2000
• Will contain
• Reconfiguration patterns
• Core alpha-OCP source code
• One Hello World example for each feature
• One comprehensive example with realistic
  application
• Users manual

43
Stuff for the 14th
44
Variable Rate Replication
uav1
uav2
100 Hz
100 Hz
20Hz
20Hz
5Hz
5Hz
uav1
Supervising Aircraft
45
Usability

• No matter how powerful the features, usability is
  important.
• Controls engineers do no necessarily know about
  threads, mutexes, CORBA etc.
• Exposing just the part of the API that will
  provide particular features is important.
  Exposing everything makes it confusing.
• It might be better to have a object for each type
  of functionality. This has the added advantage of
  being able to easily integrate into legacy code
  or other tools such as matlab, controlshell.
• Leaving the architecture of the system upto the
  user will make life easier.
• Provide good defaults with ability to customize

46
Simplicity of Code
// Other Operations (implementation) void
CSEC_LayerConfiguratorProcess1CreatePluggables
() TRACE("CSEC_LayerConfiguratorProcess1Crea
tePluggables ()") // begin
CSEC_LayerConfiguratorProcess1CreatePluggables9
13330889.body preserveyes // These creates
would probably be handled by a component level
configurator. (i.e. They might be handled by a
Controller // Manager.) // Create the
Controllers theR50UAV_Controller_ new
R50UAV_Controller(CSEC_SimulationLayerComponentIds
GetR50UAVControllerId()) theR50UAV_ExtremePer
fController_ new R50UAV_ExtremePerfController(CS
EC_SimulationLayerComponentIdsGetR50UAVExtremePe
rfControllerId()) // Create the Mode Manager
theModeManager_ new ModeManager(CSEC_Simulation
LayerComponentIdsGetModeManagerId())
theModeManager_-gtAddController(theR50UAV_Controlle
r_, UAV_ModesNORMAL) theModeManager_-gtAddCont
roller(theR50UAV_ExtremePerfController_,
UAV_ModesEXTREME) // Create the UAV
theR50UAV_ new R50UAV(CSEC_SimulationLayerCompon
entIdsGetR50UAVId()) // Create the Update
Adapter for the R50UAV theR50UpdateAdapter_
new R50UAV_UpdateAdapterMaster(theR50UAV_)
// end CSEC_LayerConfiguratorProcess1CreatePlu
ggables913330889.body void CSEC_LayerConfigura
torProcess1FinishInitPluggables ()
TRACE("CSEC_LayerConfiguratorProcess1FinishInitP
luggables ()") // begin CSEC_LayerConfigurat
orProcess1FinishInitPluggables913390573.body
preserveyes // Create the Replication
Components // R50UAV Replication //Get a
pointer to the replication manager. USROM_i
theUSROM_Ptr UInfrastructureEssentialsGetRepl
icationManagerPtr() //Create factories to
create replica objects. // Set up Event
Services to supply event UUEventSet
stateChangeEventSet UUEvent stateChangeEvent
stateChangeEvent.type_ R50UAVDATA_AVAILABLE
stateChangeEvent.source_ theR50UAV_-gtGetId()
stateChangeEventSet.Add(stateChangeEvent)

// begin module366FFD070376.includes
preserveyes include "SystemConfigurator/CSEC_Sim
ulationLayerComponentIds.h" include
"SEC_EventTypes.h" include "InfrastructureUtiliti
es/ReplicationUtilities/UU_ReplicationFactoryOSST.
h" // end module366FFD070376.includes //
Current class header include include
"SystemConfigurator/CSEC_LayerConfiguratorProcess1
.h" // Infrastructure declarations include
"InfrastructureUtilities/ConfigurationUtilities/UU
Identifier.h" // Other declarations include
"Model/UAV/R50UAV.h" include "Model/UAV/R50UAV_Up
dateAdapterMaster.h" include "Model/UAV_Control/M
odeManager.h" include "Model/UAV_Control/R50UAV_C
ontroller.h" include "Model/UAV_Control/R50UAV_Ex
tremePerfController.h" // begin
module366FFD070376.additionalDeclarations
preserveyes // end module366FFD070376.addition
alDeclarations // Class CSEC_LayerConfiguratorPr
ocess1 CSEC_LayerConfiguratorProcess1CSEC_Laye
rConfiguratorProcess1 () // begin
CSEC_LayerConfiguratorProcess1CSEC_LayerConfigur
atorProcess1913330888.hasinit preserveno //
end CSEC_LayerConfiguratorProcess1CSEC_LayerConf
iguratorProcess1913330888.hasinit // begin
CSEC_LayerConfiguratorProcess1CSEC_LayerConfigur
atorProcess1913330888.initialization
preserveyes // end CSEC_LayerConfiguratorProc
ess1CSEC_LayerConfiguratorProcess1913330888.ini
tialization TRACE("CSEC_LayerConfiguratorProce
ss1CSEC_LayerConfiguratorProcess1 ()") //
begin CSEC_LayerConfiguratorProcess1CSEC_LayerCo
nfiguratorProcess1913330888.body preserveyes
// end CSEC_LayerConfiguratorProcess1CSEC_Laye
rConfiguratorProcess1913330888.body CSEC_Laye
rConfiguratorProcess1CSEC_LayerConfiguratorProc
ess1() TRACE("CSEC_LayerConfiguratorProcess1
CSEC_LayerConfiguratorProcess1()") //
begin CSEC_LayerConfiguratorProcess1CSEC_LayerC
onfiguratorProcess1.body preserveyes delete
theR50UAV_ delete theModeManager_ delete
theR50UAV_ExtremePerfController_ delete
theR50UAV_Controller_ // end
CSEC_LayerConfiguratorProcess1CSEC_LayerConfigu
ratorProcess1.body
47
Simplicity of Code

• An object publishing data

• Most of the code you do not see because of the
  many defaults
• However you can customize by setting properties

include ocp/ocp.h include gatech/helimodelCom
ponent.h void main() // a helicopter model
(which has inherited from an output
port) HeliModel heli(uav.model) heli.init()
heli.on()    // a timer object TimerPort
timer(uav.model.timer)   // this essentially
causes timer to receive deadline timeouts at
180Hz timer.setMinRate(180)   // make the
timer call the propagate command of
heli timer.setCallBack(heli.propagate) while(1
) // sleep for infinite time since
everything is // event driven where the events
are timeouts at 180Hz sleep(INF)  
48
Simplicity of Code

• Another process that uses a replica of the model
  to visualize using a GUI

void main() HeliModelPort heli
(HeliModelPort)lookup(uav.model) heli.init()
heli.setName(userinterface.modelport) heli.se
tMaxRate(20) // in Hz heli.setMinRate(10) //
this on function turns the port on and should not
be construed // as invoking a function call on
the heli master object heli.on() runguimainl
oop()
49
DELETED SLIDES
50
Motivation for Bus Setup

• Totally decoupled communication
• Components subscribe to types of information
  with a certain Quality of Service
• The Bus (an event channel in TAO) facilitates
  this.

51
Specifying Real-TimeQuality of Service
Requirements

• Uses QoS support in underlying infrastructure
  (currently TAO)
• API allows QoS specification at run time
  (priority, frequency, period, ...)
• Concise and intuitive syntax
• Specification
• lteventgt ltsourcegt.ltevent typegt
• _at_priorityltenum valugt
• _at_freqltlvaluegt
• _at_ltQoS attributegtltlvaluegt
• Example Specification
• comp1.in1.qos "uav.PilotCommand_at_priorityHIGH_at_fr
  eq20"
• Specification is passed to real-time scheduler.

52
Ports

• Controls engineers think in terms of signals and
  block diagrams.
• An interface to a controls engineer is not IDL
  or CORBA. It is what type of signal a
  components input port will take and what type
  of signal a components output port will provide.
• We are essentially attempting to take a simulink
  block diagram and add the capability of having a
  signal come in from a remote process with a given
  Qos.

53
API Definition - Example

• Component A consumes interval events at 10 Hz and
  RouteCommand events, and it produces SetModes
  events.
• c_A.in1.qos "OCP.UAV.RouteCommand"
• c_A.in2.qos "IntervalTimeout_at_freq10" 10Hz
  interval
• c_A.out1.qos "OCP.UAV.SetModes"
• Component B consumes SetModes and VehicleState,
  and it produces PilotCommand and
  TransitionComplete events.
• c_B.in1.qos "OCP.UAV.SetModes"
• c_B.in2.qos "OCP.UAV.VehicleState"
• c_B.out1.qos "OCP.UAV.PilotCommand"
• c_B.out2.qos "OCP.UAV.TransitionComplete"

Component (cB)
...
Bus (bus1)
Bus (bus2)
Component (cA)
...
in1
out1
...
in2
out2