Software Communications

Architecture
Applications
Core Framework (CF)
OE Commercial Off-the-Shelf
(COTS)

Non-CORBA
Modem
Components
Physical
Non-CORBA
Security
Components
Non-CORBA
I/O
Components Neli Hayes
RF API

Modem Modem Link, Network Security Security Security Link, Network I/O I/O
Principal Software Architect
Components Adapter Adapter Components Adapter
SCA Core Framework Team
Components Components Adapter Components

MAC API LLC/Network API Security API LLC/Network API I/O API

JTRS Cluster 1 Program

Core Framework IDL (“Logical Software Bus” via CORBA)

CF CF

The Boeing Company, Anaheim, CA

CORBA ORB & CORBA ORB &
Services Services & Services Services &
(Middleware) Applications (Middleware) Applications

[email protected]
Operating System Operating System
Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus (714) 762-8768

Objectives
Provide an overview of reasons for creation of the SCA.
Describe what the SCA is, what it is not, and what it
enables.
Describe SCA’s maturity, and where it is being used today.
Introduce the SCA specification, supplements,
accompanying documents, available formal training, and
emerging SCA-based standards.
Provide a comprehensive overview of the SCA core
architecture rule set.
Depict example sequences of how the SCA interacts
with SCA-compliant application components.
Introduce SCA’s CORBA IDL modules.
Page 2
Outline
Why was the SCA Created? 9
– Tactical Communication Systems Limitations 10
– JTRS Program – Why? 11
– What is a Software Defined Radio? 12
– JTRS Target – A Family of Software Defined Radios 13
– Inception of the SCA 14
What is the SCA? 15
– The SCA Is… 16
– The SCA Is Not… 17

Page 3
Outline (cont.)

SCA Maturity, Where Are We Today? 18

– Phased Development to Prove the Architecture Works 19
– SCA Compliance Mandatory for JTRS Clusters 20
– Standardization Efforts 21
SCA Specifications 22
– SCA Specifications 23
– SCA Supporting Documents & Formal Training 24
– Emerging SCA-Based Standards 26

Page 4
Outline (cont.)

SW Architecture Overview 27
– What does the SCA Enable for Communication Systems? 28
– How does the SCA Enable Such Things? 29
– SCA Layering 30
– SCA Application Instantiation 31
– SCA Operating Environment 32
– SCA Core Framework and Domain Profile 33
– SCA Operating Environment Mandates 34

Page 5
Outline (cont.)

SW Architecture Overview (cont.)

– SCA Partitioning Birds Eye View 35
– SCA Partitioning Detailed View 36
– SCA Partitioning Major Divisions (Infrastructure & Application Layers) 37
– Infrastructure Layer 38
– Bus Layer 38
– Network & Serial Interface Services 39
– Operating System Layer 39
– CORBA Middleware 43
– Core Framework (CF) 45
– Application Layer 46
– CORBA-Capable Components 46
– Adapters Allowing Use of Non-CORBA-Capable Components 47
– SCA Partitioning Benefits 48

Page 6
Outline (cont.)

SW Architecture Infrastructure Layer 49

– Operating Environment (OE) 50
– Operating System & CORBA Middleware 52
– Core Framework (CF) 69
– Base Application Interfaces 75
– Framework Control Interfaces 100
– Base Device Interfaces 106
– Node Component Deployment & Removal Interface 114
– Domain Component Deployment & Removal Interface 125
– Application Installation/Un-installation Interface 125
– Application Creation Interface 132
– Application Configuration/Control/Termination Interface 139
– File Service Interfaces 152
– Domain Profile – Component Packaging & Deployment 157

Page 7
Outline (cont.)

How CF Interacts with Application Components 189

– Node Startup 191
– DeviceManager Startup 191
– Creation of persistent devices and services 192
– Deployment of persistent devices and services to the CF domain 193
– Application Installation 194
– Application Instantiation 196
– Creation of a Single Application Component 197
– Connecting Application Components Together 199
– Invoking Operations on a Single Application Component 201
– Application Tear-Down 202
SCA IDL Modules 203
References 210

Page 8
Why was the SCA
Created?
Tactical Communication
Systems Limitations

Evolved to meet service-specific and mission-

specific requirements.
• Cannot communicate with each other.
• Cannot take advantage of rapid advances in
technology in a timely and cost-effective manner.

Hence, the Joint Tactical Radio System (JTRS)

Program was formed.

Page 10
JTRS Program – Why?
DOD Complaints to JTRS Program
Radio Manufacturers:
A DOD Joint Program for an
information warfare communication
“We can’t support all your
system built on a family of HF-to-L-
discrete radios”
band radios with a common open
architecture with these…
“We can’t fight the way we E
want to with your discrete AR
Requirements F TW D
radios” S O E
• Software controlled and
FIN
reprogrammable DE I O
“We can’t introduce new D
technology at the pace of
• Modular and scaleable RA
• Extensive use of COTS technology
commercial industry” • Simplified applications engineering
• Rapid deployment of system
improvements
Page 11
What is a Software Defined
Radio?
Collection of hardware and software technologies that enable
reconfigurable system architectures for wireless networks and user
terminals.

Efficient and comparatively inexpensive solution for building

multimode, multi-band, multifunctional wireless devices that can be
adapted, updated, or enhanced using software upgrades.

SDR Concepts Allow

• Standard, open, flexible architectures.
• Enhanced wireless roaming by extending capabilities of current and
emerging commercial air interface standards.
• Over-the-air downloads of new services, features, software patches.
• Advanced networking capabilities allowing truly portable networks.
• Unified communication across commercial, civil, federal and military
organizations.
• And, therefore, significant life-cycle reduction costs.
http://www.sdrforum.org Page 12
JTRS Target – A Family of
Software Defined Radios
Radio functionality Provided through Software (versus Hardware)
– Mostly software applications (rather than hardware components) provide
waveform generation and processing, encryption, signal processing, and other
major communications functions.
Programmable
– Can accommodate various physical layer formats and protocols.
– Multiple software modules allow implementation of different standards in the
same radio system.
– Can be altered to implement both legacy communication systems as well as
those yet to be defined.
Reconfigurable
– Support dynamic partitioning of radio resources and re-characterization of radio
in response to user needs.
Easily Upgradeable
– New/improved functionality easily incorporated, w/o need to upgrade/replace
hardware components.
Responsive
– Can dynamically modify their operation in response to changes in environment.
Less Costly Maintenance
– Over-the-air downloads of features, services, software patches.
Page 13
Inception of the SCA

Four of the top defense radio manufacturers get

together and define a standard software
architecture--the Software
Communications Architecture (SCA)--
that can support the JTRS Requirements.
– The Modular Software-programmable Radio
Consortium (MSRC)
ƒ Raytheon, BAE SYSTEMS, Rockwell-Collins, ITT

Page 14
What is the SCA?
The SCA is…
An Open Architecture Series of Mandated
Framework Interfaces, Behavioral
Based on Specifications and
• CORBA Requirements
• CORBAservices Promote component portability,
• CORBA Component Model interchangeability, and interoperability,
• POSIX software reuse, and architecture scalability.
Expressed in
• CORBA IDL
Standard
For communication platform hardware &
• UML
software design engineers to ensure a
• XML system’s SCA-compliancy just as a building
architect or planner uses a local building
code to design and build homes to ensure
sound construction and safety.

Page 16
The SCA Is Not…
Is not a system specification.
• It is a set of rules that constrain the design of systems, to
achieve SCA objectives.
Is not a design specification.
• Does not tell hardware and software designers how to design
their equipment and programs.
• SCA requirements limited to those necessary to meet SCA-
compliant system criteria, w/o restricting innovation or domain-
specific requirements.
Is not an implementation architecture.
• There are many valid definitions of an SCA architecture.
• A particular SCA implementation architecture is a result of
joining between the SCA, the particular domain and project
technical specifications, and other procurement requirements.
Page 17
SCA Maturity
Where is it Today?
Phased Development to Prove
the Architecture Works
JTRS Step 1 – Architecture Development
– MSRC members develop initial architecture
JTRS Step 2a – Architecture Feasibility
– MSRC members deliver prototype radios -- SCA Core Framework and waveform
implementations
– Specification maturation
– Pursue commercial acceptance (OMG/SDR Forum)
JTRS Step 2b – Independent Architecture Validation
– Non-MSRC members deliver prototype radios
ƒ Harris/General Dynamics deliver prototype radios
ƒ Boeing – Delivers SCA Core Framework
ƒ Thales/Vanu provides handheld radios
ƒ Rockwell-Collins provides prototype waveform software
JTRS Step 2c – Ruggedized Fieldable Radio
– BAE SYSTEMS chosen to deliver SCA compliant radios for field evaluation
Page 19
SCA Compliance Mandatory on
JTRS Clusters ell as any DoD Propgeraramtiionns (NCO)
vo lv ed with

As w k C en t ric O
Networ and CW)
ar e ( N
C e n t ri c Warf
Cluster 1 Networ
k
– Multi-channel software programmable, hardware-configurable digital
radio networking system for the Army.
Cluster 2
– Handheld and man-pack radios for the Army, Navy Marine Corps and
Air Force.
AMF (JTRS Airborne and Maritime/Fixed Station, Mergers of Clusters 3 & 4)
– Acquisition of JTR sets for Air Force and Navy platforms.
Cluster 5
– JTRS hand-held and man pack units for embedded platforms suitable
for Small Form Fit (SFF) radios.
Future Clusters
– Will respond to interests from the Homeland and Security operational
communities and evolving DoD requirements
Public Domain Detail at http://jtrs.army.mil/
Page 20
Standardization Efforts
JTRS SCA Technical Architecture Group (TAG)
– An SCA discussion forum, invites the JTRS community members to propose and develop
change proposals to the SCA and its related appendices and supplements. Oversees
submitted changes and leads effort to research, accept or reject each change proposal.
– https://jtel-sca.spawar.navy.mil/
Software Defined Radio Forum (SDRF)
– Working with JTRS JPO, adopted the SCA in 2000 as a body of work mature enough to
move out to a formal standards body, the Object Management Group (OMG). Involved with
development of SCA-based software radio standards.
– http://www.sdrforum.org/
OMG Software-Based Communication Domain Task Force (DTF)
– Former OMG Software Radio Domain Special Interest Group (DSIG)
– With JPO sponsorship, works toward building an international commercial standard based
on the SCA. Most recent efforts include the PIM & PSM for Software Radio Components
Joint Revised Submission.
– http://sbc.omg.org
International Acceptance
– Individual nations, such as France and Sweden have adopted or are considering adopting
forms of the SCA.
– The US and others are also working within NATO to have the SCA adopted.

Page 21
SCA Specifications,
Supporting Documents,
Training, Emerging SCA-
Based Standards
SCA Specifications

SCA SCA SCA

Specification Application Security
V2.2.1 Program Supplement
Interface V2.2.1
Supplement
V2.2.1

Basic Common APIs Security

architecture beyond the SCA requirements for
definition & rule core rule set & SCA-compliant
sets governing standards for systems.
SCA-compliant defining app-
hardware and specific common
software APIs to promote
development. further app
portability.
Available at http://jtrs.army.mil/
Page 23
SCA Specifications

04
Specialized
s t 20
HW
g u
Au
Supplement to
the SCA

CB
V3.0

A C
S C
Portability for specialized hardware such as

b y
• Field Programmable Gate Arrays (FPGA)

d
• Digital Signal Processors (DSP)
e
ov
• Application Specific Integrated Circuits (ASIC))

p r
In particular, it specifies

Ap
• a Hardware Abstraction Layer Connectivity (HAL-C) specification
• a reduced POSIX AEP for DSP environments,
• Waveform functional blocks to be provided as part of each radio set
• an Application Interface for antenna interfaces.

Draft July 9, 2004 available at http://jtrs.army.mil/

Page 24
SCA Supporting
Documents & Training

SCA SCA SCA

Support Developers Training
& Guide Course
Rationale V1.1
Document
V2.2

Rationale behind Design guidelines • SCA Overview

architectural rule for developing • Security & APIs
set decisions SCA-compliant • Application Design
accompanied applications and • Application XML Files
with supporting devices. • Porting and Test
material.

Available at http://jtrs.army.mil/
Page 25
 Emerging SCA-Based
Standards
Based on the SCA. Defines platform independent
Highly recommended reading PIM & PSM model and a UML Software
for SCA software radio system for Software Profile for software radios,
and software engineers and describing in great detail, all
Radio
architects, specially on JTRS common aspects of a software
and related programs.
Components radio (i.e. the entire radio
Sheds a lot of light on the SCA April 2004 management infrastructure,
CF infrastructure, how it relates radio devices and services, and
to software radio concepts. …), explaining concepts such as
communication channels, and
how these concepts map to the
SCA infrastructure (for example
exactly what is a communication
channel and how does it map to
the SCA infrastructure for CF,
devices, services, and the
operating environment).
Available at http://www.omg.org/cgi-bin/doc?sbc/2004-04-01
Page 26
Software Architecture
Overview
What does the SCA Enable for
Communication Systems?
– Maximum independence of software from specific hardware
solutions.
– Portability of applications software across diverse SCA-compliant
platforms in the same domain.
– Interoperability of applications software.
– Reuse of common software across these platforms
– Scalability across platforms – same architecture from handheld to
base station.

Applications A .. Z Domain Services

SCA
Domain Hardware
Page 28
How does the SCA Enable
Such Things?
– Defines a distributed, object-oriented, language-independent, and
platform-independent operating environment with common
software interfaces and framework.
ƒ For deployment, configuration, and tear down of applications, and
management of the domain that hosts these applications.
– Defines a standard way to package and deploy application components.
– Separates applications from the operating environment.
– Segments application functionality.
– Defines and provides the means for defining application-specific
common services and APIs.
ƒ To promote further application portability.
Applications A .. Z Domain Services

SCA
Domain Hardware
Page 29
 SCA Layering
Limited to use OS services designated mandatory in SCA AEP
Developed using
CF
Core Base Application Core

SCA Operating Environment (OE)

Framework Application Framework
Interfaces Components

Forms Domain Platform

Allowed extensions/services beyond minimumCORBA:
Naming, Event, & LW Log Service (SCA V2.2.1)

Subset of
POSIX Framework Control Framework
Provides Interfaces Services
Minimum AEP
OS
Capability CORBA CORBA
Software Bus Software Bus
&
Application
OS Operating System
Portability Must Support the Application Environment Profile (AEP)

Device Drivers
Page 30
SCA Application Instantiation

Application
load/execute
Instance

Physical Element Physical Element

Application
Factory Device Device
Do

Reads Installed
m

Files
ai
n
Pr

Application
of
ile

Instance

Connects
components

Page 31
SCA Operating Environment
Operating Environment (OE) – forms domain platform
– Core Framework
– Domain Profile
– CORBA middleware (software bus)
– Application Environment Profile
ƒ Defined by SCA to provide minimum operating system functionality
– Operating System
– Device Drivers
OE’s Job
– Impose design constraints on applications to provide increased
portability of applications from one SCA-compliant platform to another
– Specified interfaces between the CF and application software.
– Restrictions on applications’ usage of OS and CORBA middleware
APIs.

Page 32
CF and Domain Profile
Core Framework (CF)
– Set of software interfaces and profiles that provide for the deployment,
management, interconnection, and intercommunication of software
application components in embedded communication systems, using
CORBA to communicate between entities.
Domain Profile
– XML files that describe:
ƒ Individual components of a software application.
ƒ How the components are interconnected.
ƒ Component properties.
ƒ Properties of hardware device abstractions.

Page 33
SCA OE Mandates
RTOS
– RTOS must Support SCA Application Environment Profile (AEP).
– The SCA AEP is a subset of the POSIX.13 Real-time Controller System
Profile (PSE52).
– Applications are limited to using the RTOS services that are designated
as mandatory in the SCA AEP.
CORBA
– No extensions and/or services beyond Minimum CORBA can be used
except as specified in the SCA.
ƒ CORBA Naming Service
ƒ CORBA Event Service
ƒ OMG Light Weight Log Service (SCA V2.2.1)
– Desired extensions listed as optional, pending commercial availability
ƒ Interoperable Naming Service
ƒ Real-Time CORBA
ƒ CORBA Messaging

Page 34
SCA Partitioning
Birds Eye View
Application Layer Software
Components

App C App D App E

App A App B
SCA Application Layer App F

SCA Infrastructure Layer

Domain Hardware

Page 35
 SCA Partitioning
Detailed View
APPLICATION LAYER Applications
Core Framework (CF)
INFRASTRUCTURE
Commercial Off-the-Shelf
LAYER (COTS)

Non-CORBA Non-CORBA Non-CORBA

App B App D App F
Components Components Components

App A

App B App B App C App D App D App D App E App F App F

Components Adapter Components Adapter Components Adapter Components Adapter Components

MAC API LLC/Network API Security API LLC/Network API I/O API

Core Framework IDL (“Logical Software Bus” via CORBA)

CORBA ORB & CF CORBA ORB & CF

Services Services & Services Services &
(Middleware) Applications (Middleware) Applications

Operating System Operating System

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 36
 SCA Partitioning
Major Divisions
APPLICATION LAYER Applications
Core Framework (CF)
INFRASTRUCTURE
Commercial Off-the-Shelf
LAYER (COTS)

Non-CORBA
App B
Application Non-CORBA
App D
Non-CORBA
App F
Components Layer Components Components

App A

App B App B App C App D App D App D App E App F App F

Components Adapter Components Adapter Components Adapter Components Adapter Components

App B API App C API App D API App E API App F API

Core Framework IDL (“Logical Software Bus” via CORBA)

Infrastructure Layer

CORBA ORB & CF CORBA ORB & CF

Services Services & Services Services &
(Middleware) Applications (Middleware) Applications

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Operating System Operating System

Black Hardware Bus Red Hardware Bus

Page 37
Infrastructure
Bus Layer INFRASTRUCTURE
LAYER
Commercial Off-the-Shelf
(COTS)

• Transport mechanisms that perform error checking and correction at the

bus support level.
• Possible commercial bus architectures: VME, PCI, CompactPCI,
Firewire, Ethernet, etc..
• Different bus architectures could be used on the Red and Black
Subsystems.

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 38
Infrastructure
Network & Serial
Interface Services
INFRASTRUCTURE
Commercial Off-the-Shelf
LAYER (COTS)

• Commercial components support multiple unique serial and network

interfaces.
• RS-232, RS-422, RS-423, RS-485, Ethernet, 802.x, etc.).
• To support these interfaces, various low-level network protocols may be
used (e.g. PPP, SLIP, LAPx, and others).

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 39
Infrastructure
OS Layer INFRASTRUCTURE
LAYER
Commercial Off-the-Shelf
(COTS)

Real-time embedded OS functions provide needed support for Infrastructure and

Application layers. For example:
• Booting the processor
• Multi-threading support
• I/O support
• Inter-process and inter-device support
• Other general-purpose capabilities required for real-time embedded
applications
As such, may be present on all CORBA-capable processors in a system.

Operating System Operating System

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 40
Infrastructure
OS Layer (cont.) INFRASTRUCTURE
LAYER
Commercial Off-the-Shelf
(COTS)

May be tailored to support specific target/board environments. For example:

• A Board Support Package (BSP), can tailor the RTOS for specific
processor board elements, including the device drivers that support the
specific devices/chip sets resident on the board.
• Device drivers to support the necessary inter-processor communication
required by the ORB.

Operating System Operating System

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 41
Infrastructure
OS Layer (cont.) INFRASTRUCTURE
LAYER
Commercial Off-the-Shelf
(COTS)

A standard OS interface is required to facilitate portability of applications. As

POSIX is an accepted industry standard, and POSIX and its real-time extensions
are compatible with the requirements to support the OMG CORBA specification,
the SCA defines a minimal POSIX profile, known as the SCA Application
Environment Profile (AEP; SCA Appendix A), based on the Real-time
Controller System Profile (PSE52) as defined in POSIX 1003.13, to meet SCA
requirements. More on OS usage restrictions enforced on the Infrastructure and
Application Layers later.

Operating System Operating System

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 42
Infrastructure
CORBA Middleware INFRASTRUCTURE
LAYER
Commercial Off-the-Shelf
(COTS)

Distributed processing is a fundamental aspect of the system

architecture and is based on the OMG CORBA specification. It is
used in the Infrastructure Layer as the message passing technique
for the distributed processing environment.

Why CORBA?

CORBA ORB & CORBA ORB &

Services Services
( Middleware) ( Middleware)

Operating System Operating System

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 43
 Infrastructure CORBA
Middleware (cont.) INFRASTRUCTURE
LAYER
Commercial Off-the-Shelf
(COTS)

OMG’s CORBA specification: a specification for a “software bus” or “software back plane”.
The “software bus” and the middleware for the

• Middleware for establishing relationships between clients and servers in a distributed

system.
• Provides interoperability between applications on different machines, difference OSs,
different networking protocols, and different programming languages.
• Supports location transparent invocation of server objects by client objects.
• Components are “plugged into” the software bus, and are visible to other components.
• More later on the ORB and CORBA services used in the Infrastructure Layer.
SCA OE.

CORBA ORB & CORBA ORB &

Services Services
( Middleware) ( Middleware)

Operating System Operating System

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 44
Infrastructure
Core Framework INFRASTRUCTURE
LAYER
Core Framework (CF)
Commercial Off-the-Shelf
(COTS)

The CF is the essential (“core”) set of open application-layer

interfaces and services to provide an abstraction of the
underlying software and hardware layers for software
application designers. More on CF later.

Core Framework IDL (“Logical Software Bus” via CORBA)

CORBA ORB & CF CORBA ORB & CF

Services Services & Services Services &
( Middleware) Applications ( Middleware) Applications

Operating System Operating System

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 45
 Application Layer
CORBA Capable APPLICATION LAYER Applications
Core Framework (CF)

Components
INFRASTRUCTURE
Commercial Off-the-Shelf
LAYER (COTS)

Applications perform user level functions.

Direct OS access limited to SCA POSIX

App A

App B App C App D App E App F

Components Components Components Components Components

App B API App C API App DAPI App E API App F API
interfaces & services.

SCA POSIX Profile

SCA POSIX Profile
SCA POSIX Profile

SCA POSIX Profile

Required to use CF

le
file

ro f i

Profile.
Core Framework IDL (“Logical Software Bus” via CORBA)

Pro

P
IX
IX

POS
POS

CORBA ORB & CF CORBA ORB & CF

A
SCA

C
Services Services & Services Services &

S
(Middleware) Applications (Middleware) Applications

Operating System Operating System

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 46
 Adapters Allowing Use of Non-CORBA
Capable Components APPLICATION LAYER Applications

in the Application Layer

Core Framework (CF)
INFRASTRUCTURE
Commercial Off-the-Shelf
LAYER (COTS)

• Based on Adapter
Non-CORBA
Design Pattern Non-CORBA • Implement CF Interface Non-CORBA
App B • Translate between App D • Translation transparent to App E
Components “Legacy” & CORBA- Components
CORBA-capable components Components
capable components
App A

App B Modem App C App D App D App D App E App E App E

Components Adapter Components Adapter Components Adapter Components Adapter Components

MAC API LLC/Network API Security API LLC/Network API I/O API

Core Framework IDL (“Logical Software Bus” via CORBA)

CORBA ORB & CF CORBA ORB & CF

Services Services & Services Services &
(Middleware) Applications (Middleware) Applications

Operating System Operating System

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 47
SCA Partitioning Benefits

Maximizes use of commercial protocols and

products.
Isolates core and non-core applications from
underlying hardware through multiple layers of
open, commercial software infrastructure.
Provides for a distributed processing environment
through CORBA.
Hence, provides software application portability,
reusability, and scalability.

Page 48
Infrastructure Layer
Operating Environment
 Operating
Environment
INFTRASTRUCTURE Applications
LAYER Core Framework (CF)
OPERATING Commercial Off-the-Shelf
ENVIRONMENT (COTS)

Non-CORBA
ORB Non-CORBA CF Non-CORBA
App B Naming Service App D App F
Components Components Components
Event Service
LW Log Service V2.2.1
App A

App B App B App C App D App D App D App E App F App F

Components Adapter Components Adapter Components Adapter Components Adapter Components

App B API App C API App D API App E API App F API
Operating Environment

Core Framework IDL (“Logical Software Bus” via CORBA)

CORBA ORB & CF CORBA ORB & CF

Services Services & Services Services &
(Middleware) Applications (Middleware) Applications

Operating System Operating System

Network Stacks & Serial Interface Services Network Stacks & Serial Interface Services

Board Support Package (Bus Layer) Board Support Package (Bus Layer)

Black Hardware Bus Red Hardware Bus

Page 50
Operating Environment’s
Job
INFTRASTRUCTURE Applications
LAYER Core Framework (CF)
OPERATING Commercial Off-the-Shelf
ENVIRONMENT (COTS)

Impose design constraints on applications.

– To provide increased portability of applications from
one SCA-compliant platform to another.
These design constraints include:
– Specified interfaces between the CF and application
software.
– Restrictions on applications’ usage of OS and CORBA
middleware APIs.

Page 51
Operating Environment
Operating System
 OE

OS Usage Restrictions
Operating System

Commercial Off-the-Shelf
(COTS)

a p p li c a ti o n s u s e C F f o r L o g ic a l D e v ic e is a n A d a p te r fo r
CO RBA A PI a l l F il e a c c e s s H W - s p e c i fic d e v ic e s
M o r e o n L o g i c a l D e v i c e la t e r

A l l A p p li c a t i o n C o m p o n e n t s

C ore F ram ew ork :

F r a m e w or k C on tr ol &
F r a m e w o r k S e r v ic e s In ter fa c e s

CO RBA O RB n on -C O R B A c om p on e n ts
or
d e v ic e d r iv e r s
O S a ccess O S a ccess (n on -C O R B A
O S a ccess
lim ite d to co m p o n en ts p r o v id e
u n l im it e d u n l im it e d
SCA AEP a c c ess to h ar d w ar e
d e v i c e s / f u n c ti o n a l it y
O S (fu n c tio n ) th a t su p p o r ts S C A A E P . n o t a v a i la b l e o n a
C O R B A -ca p a b le
( u n l im it e d p r o p r i e ta r y A P I s f o r s y s t e m p rocessor)
d e v e lo p m e n t).

A n y v en d o r -p r o v id e d O S
f u n c t i o n c a ll s

Page 53
Operating Environment
Object Request Broker
 OE
CORBA Middleware

Object Request Broker

ORB

Commercial Off-the-Shelf
(COTS)
Components “plug” into

bus” and become visible

• Infrastructure Layer OE components (e.g. CF)

the CORBA “software

to other components.

• Application Layer components

Client&
Client &
Client
Client Server
Server Server
Server

ORB (SCA OE Software Bus)

As of SCA V2.2, all Infrastructure Adapter wrapping a Legacy

and Application Layer components Legacy
Legacy non-CORBA capable
are restricted to minimumCORBA Code
Code Application Layer component
for portability. with a CORBA wrapper.

Page 55
Operating Environment
CORBA Naming Service
 OE
CORBA Middleware

Naming Service
Naming Service

Commercial Off-the-Shelf
(COTS)

3: Request Services
Client
Client Server
Server
2: Clients find object references distributed 1: Servers bind their objects
throughout the system by their assigned name to names so that clients can find them
• A CORBA server that
associates human
• Centralized
readable names with Naming
Naming repository of
CORBA object references.
• Based on OMG Naming Service
Service object
references in
Service Specification
the CORBA
OMG Document
environment.
formal/00-11/01.
• Must support bind(), • Server
bind_new_context(), Bindings
unbind(), destroy(), organized in
resolve(). Naming
Contexts.
Page 57
 Naming Service Usage OE
CORBA Middleware

in the OE
Naming Service

Commercial Off-the-Shelf
(COTS)

Typical OE Naming Service Servers

• CF component that installs applications in the CF domain
Typical OE Naming • Deployed domain components
Service Clients • Instantiated application components
• CF: connect deployed
components to services 3: Request Services
in CF domain Client
Client Server
Server
• Application Layer
components: installation 2: Clients find object ORs distributed 1: Servers bind their objects
of application software throughout the system by their assigned name to names so that clients can find them
through CF
• CF: create, setup,
connect, and tear down
instantiated application
Naming
Naming
components. Service
Service
• More on this later.

Page 58
Operating Environment
CORBA Event Service
 OE
CORBA Middleware

Event Service
Event Service

Commercial Off-the-Shelf
(COTS)

Based on OMG’s Event Service specification.

– Push interfaces (PushConsumer and PushSupplier) of the
CosEventComm CORBA module as described in OMG Document
formal/01-03-01: Event Service, v1.1.
– Compatible IDL for the CosEventComm CORBA module in the OMG
Document formal/01-03-02: Event Service IDL, v1.1.
Decoupled, asynchronous communication model between clients and
servers.
– Event producers and consumers
Suppliers “publish” information without knowing who the consumers
are.
Consumers “subscribe” to information without regard to the
information source.
Suppliers are shielded from exceptions resulting from any of the
consumer objects being unreachable or poorly behaved.

Page 60
 OE
CORBA Middleware

Event Service
Event Service

(cont.) Commercial Off-the-Shelf

(COTS)

Central Role in Event Service Specification

• Supplier(s)/consumer(s) intermediary.
• Acts as consumer to supplier(s) and supplier to consumer(s).
• Supplier and consumer registrations.
• Timely and reliable event delivery to all registered consumers.
• Error handling associated with unresponsive consumers.
push push
Consumer11
C o n s u m e r
Supplier11
Supplier Consumer

S u p p l i e r
push push
Supplier22
Supplier Consumer22
Consumer
push Event Channel push
Supplier…
Supplier … Consumer…
Consumer …
push push
SupplierNN
Supplier ConsumerNN
Consumer

Page 61
Event Service Usage OE
CORBA Middleware

in the OE
Event Service

Commercial Off-the-Shelf
(COTS)

Used by CF for
• Connection of CF domain components to required event channels, and
• Connection/disconnection of application components to required event channels in
the CF domain, during instantiation/tear down of an application in the CF domain.
• Logging SCA-specified events to SCA-specified event channels.

push push
Consumer11
C o n s u m e r
Supplier11
Supplier Consumer

S u p p l i e r
push push
Supplier22
Supplier Consumer22
Consumer
push Event Channel push
Supplier…
Supplier … Consumer…
Consumer …
push push
SupplierNN
Supplier ConsumerNN
Consumer

Page 62
Event Service Usage OE
CORBA Middleware

in the OE (cont.)
Event Service

Commercial Off-the-Shelf
(COTS)

OE provides two standard event channels:

– Incoming Domain Management Event Channel
ƒ Allows the CF domain to become aware of changes in the domain.
• e.g. device state changes.
– Outgoing Domain Management Event Channel
ƒ Allows CF domain clients to become aware of changes in the
domain.
• e.g. Human Computer Interface (HCI) application receiving
events pertaining to device/service/application
software/instantiated application additions/removals from
domain.
Application developers allowed to setup other “non-standard” event
channels.

Page 63
Operating Environment
Log Service
 e i g ht
igh t W
L
Log Service ced with O M G
A V 2 .2 . 1 …
Repla ervice in S C
L og S
SCA V2.2 provides one interface (Log) and types
for log producers, consumers, and
administrators to generate standard SCA log
records, consume them, get status from the clog,
e into
in t e r fa
and control the logging output of e Laolog
g
producer. d e s t h e s f o r …
h ich d iv i interf a c
… w p a ra te
o ur s e
Log producers are F
required to implement
configure properties that configure the c e r s ,
producer’s log record output. P ro d u
s ur s,
m e
g C o n r s , a n d
…Lo m in is t r a t o
r s
Ad R e t rie v e
Statu s Page 65
 Log Interface
INFTRASTRUCTURE
LAYER Log Service
OPERATING Commercial Off-the-Shelf
ENVIRONMENT (COTS)

<<Interface>>
Log

clearLog() : void
destroy() : void SCA V2.2.1
setAdministrativeState(state : in AdministrativeStateType) : void CosLwLog::LogAdministrator
setLogFullAction(action : in LogFullActionType) : void
setMaxSize(size : in unsigned long long) : void
getAdministrativeState() : AdministrativeStateType
getAvailabilityStatus() : AvailabilityStatusType
getCurrentSize() : unsigned long long SCA V2.2.1
getLogFullAction() : LogFullActionType
getMaxSize() : unsigned long long
CosLwLog::LogStatus
getNumRecords() : unsigned long long SCA V2.2.1
getOperationalState() : OperationalStateType CosLwLog::LogConsumer
getRecordIdFromTime(fromTime : in LogTimeType) : RecordIdType
retrieveById(currentId : inout RecordIdType, howMany : in unsigned long) : LogRecordSequence
writeRecords(records : in ProducerLogRecordSequence) : void SCA V2.2.1
CosLwLog::LogProducer

Page 66
Log Service Usage
by CF
INFTRASTRUCTURE
LAYER Log Service
OPERATING Commercial Off-the-Shelf
ENVIRONMENT (COTS)

c e d with
Repl a
r o d ucer
o g :: L og P
L
CosLw SCA V2.2.1
in

Unsuccessful device/service • Application installation/uninstallation

registration/unregistration results in CF domain
results with DeviceManager • DeviceManager/device/service
registration/unregistration results in CF
domain

Application tear-down results Application instantiation results in CF

in CF domain domain

Page 67
Log Service Implementation and
Deployment Optional INFTRASTRUCTURE

in the OE
LAYER Log Service
OPERATING Commercial Off-the-Shelf
ENVIRONMENT (COTS)

A CF provider may deliver an SCA-compliant product

without a Log Service implementation.
An SCA-compliant installation (e.g., a handheld platform
with limited resources) may choose not to deploy a Log
Service as part of its domain.
CF components that are required to write log records are
also required to account for the absence of a log service
and otherwise operate normally.

Page 68
Operating Environment
Core Framework
Core Framework
INFTRASTRUCTURE
LAYER Core Framework (CF)
OPERATING Commercial Off-the-Shelf
ENVIRONMENT (COTS)

The essential (“core”) set of open application-layer

interfaces and services that
– Provide an abstraction of the underlying software and hardware
layers for software application designers.
– Provide for deployment, management, interconnection, and
intercommunication of software application components in a
distributed embedded communication system.
– Through imposed design constraints provide increased
portability of these application components from one SCA-
compliant platform to another.
ƒ Specified interfaces between CF and application software.
ƒ Specified behavioral requirements for application software.

Page 70
CF Interfaces
Top-Level View

Page 71
CF Interface
Groupings
Base Application
Interfaces

File Service
Interfaces
Framework
Control Interfaces

Page 72
 CF Interfaces and Services

Base Application Interfaces (Port, LifeCycle, TestableObject,

PropertySet, PortSupplier, ResourceFactory, and Resource) that
provide a common set of interfaces for developing software application
components and exchanging information between them.
Framework Control Interfaces that provide the means for control and
management of hardware assets, applications, and domain (system).
- Device Interfaces (Device, LoadableDevice, ExecutableDevice,
AggregateDevice)
- Device Management Interfaces (DeviceManager)
- Domain Management Interfaces (Application,
ApplicationFactory, DomainManager)
File Service Interfaces (File, FileSystem, FileManager) that provide the
means for distributed file access services.

Page 73
 CF Component Packaging
and Deployment
The Domain Profile, is a series of eXtensible Markup
Language (XML) files, based on…

the CORBA Component Specification, and

SCA-defined XML Document Type Definitions (DTDs)…

…expressing the packaging and deployment of software

application components and related hardware assets
into an SCA-compliant system.

Page 74
CF Base Application
Interfaces
 CF Base Application
Interfaces
Defined by CF requirements, implemented by application developers.
Testing component Configuring/retrieving
Managing associations Obtaining a selected Initializing and
implementations component
between logical com. consumer or producer releasing component-
properties/attributes
channels for Port specific data for
transferring data/control instantiated SCA-
between SCA-compliant compliant software
software components components

Creating/destroying
Resources, obtaining a
resource without
Common API for knowing its identity
control and
configuration of a
software component

Unimplemented framework of operations for creation, initialization,

configuration, control, test, and tear down of application
components in the system.
Page 76
Port Interface
Provides a specialized connectivity to a component. Used to setup and tear down
connections between CORBA components (mainly application components) in the
CF domain. How?

<<Interface>>
Port

connectPort(connection : in Object, connectionId : in string) : void

disconnectPort(connectionId : in string) : void

Page 77
A Component can have a Set
of Ports

A component may have 0 or more ports as

needed.
The implementation for each port is specific to the
component.

Page 78
A Component Defines a
Component-Specific Port by…
Creating a specific port type by defining an interface that
inherits from Port.
– Port Types
ƒ Command and Control, Data, Status.
ƒ Basic push and pull Ports defined in the SCA.
Establishing the operations for transferring data and
control.
Establishing the meaning of data and control values.
Specifying whether the port is a “uses” or a “provides”
port.

Page 79
“Uses” and “Provides”
Ports

Uses Port
– A port that uses some set of services provided by a
provider component.
– All uses ports implement the Port interface.
Provides Port
– A port that provides some set of services at an
interface.

Page 80
How do Component Ports
get Connected?
Connection Definitions
– Definition of how the component ports get connected is
described in the following Domain Profile files:
ƒ (An application’s) Software Assembly Descriptor
ƒ (A CF domain node’s) Device Configuration Descriptor
ƒ Covered later when we go over the Domain Profile.
By Whom?
– Ports are connected by CF’s Framework Control Interfaces in
charge of deploying and managing components in the CF
domain (i.e. DomainManager), and instantiating applications in
the CF domain (i.e. ApplicationFactory).
How?
– Covered later when we cover CF’s Framework Control Interfaces
(DomainManager and ApplicationFactory).
Page 81
Port Interface Advantages

Supports the connection concepts in the CORBA

Components Specification where any provides port type
can be connected to another uses port, as long the uses
port understands the port, which it is connecting.
The uses port can be behave either as a push producer or
a pull consumer. Likewise, the provides port type can be
behave either as a push consumer or pull producer.
The fan-in, fan-out, or on-one-on implementation of a port
is allowed, and is component dependent.

Page 82
PortSupplier Interface
Provides the means for a component that has a Port to make the Port available to
those who need it. Mainly, those in charge of connecting the Port to other(s).

<<Interface>>
PortSuppli er

getPort(name : in string) : Object

Page 83
Use of PortSupplier
Interface in CF

The main PortSupplier interface users in the CF are the

Framework Control interfaces DomainManager (during
deploying components to the CF domain) and
ApplicationFactory (during instantiation of an application
in the CF domain).
They use a component’s getPort operation, as directed by
the Domain Profile, to retrieve uses and provides ports
in order to connect the component to services or other
components in the domain.

Page 84
LifeCycle Interface
Provides a generic means for initializing and releasing a resource, application, or
device in the CF domain.

<<Interface>>
LifeCycle

initialize() : void
releaseObject() : void

Page 85
LifeCycle Users

The component initialization LifeCycle interface users in the

CF are the Framework Control interfaces DeviceManager
(during deploying components to the CF domain) and
ApplicationFactory (during instantiation an application in
the CF domain), after a component has been deployed
and its object reference has been obtained.
The component tear-down LifeCycle interface users in the
CF are the Human Control Interface (HCI) or other
domain client to release an application or device, and
the CF Application interface to release an application’s
components as a part of application termination.

Page 86
 TestableObject Interface
Provides a generic means for black box testing a resource, application, or device
in the CF domain.

<<Interface>>
TestableObject

runTest(testid : in unsigned long, testValues : inout Properties) : void

Location of Component Test IDs, Input, and Output Values

Component’s Properties Descriptor referenced from the component’s Software
Package Descriptor in the CF Domain Profile.

Page 87
TestableObject Interface
Uses and Advantages

May be used by an HCI to test an Application or Device

component within the domain.
Using this interface, it would be possible to implement a
generic HCI that could work for all Applications and
Devices since this interface is based upon a CF Domain
Profile XML element.
Currently there is no requirement to perform initial testing
of a deployed domain component DeviceManager or an
application’s components by the ApplicationFactory.

Page 88
PropertySet Interface
Provides a generic means of configuring and retrieving a component’s properties.

<<Interface>>
PropertySet

configure(configProperties : in Properties) : void

query(configProperties : inout Properties) : void

Page 89
Properties Sequence
Properties or id
(name)/value pairs, is a <<CORBATypedef>>
concept from the Properties
CORBA Components,
Telecommunications
Information
Networking
Architecture (TINA),
and CORBA property <<CORBAStruct>>
service specifications. DataType
id : string
value : any

Page 90
Use of PropertySet
Interface in CF

If the component has any configure properties defined in

the CF Domain Profile, this interface is used to configure
the component by DeviceManager (during deploying
components to the CF domain) and ApplicationFactory
(during instantiation of an application in the CF domain),
after the component has been deployed and its object
reference has been obtained.
Can also be used by a HCI to configure an Application,
Device, DeviceManager, and DomainManager within the
domain.

Page 91
PropertySet Interface
Advantages

Promotes the possibility of having a generic HCI based on

the corresponding CF Domain Profile XML element to
configure and query components.
Provides the capability of adding configure and query
properties to a component’s implementation without
having to change an IDL interface definition.
– In this case, the component’s appropriate Domain Profile XML
file would have to be updated.

Page 92
 Resource Interface
<<Interface>> <<Interface>> <<Interface>> <<Int erface>>
PortSupplier LifeCycle PropertySet TestableObject

getPort() initialize() configure() runTest()

releaseObject() query()

<<Interface>>
Resource
Unique identifier, so that Specialization of a minimal
identifier : string set of interfaces needed to
each component logging
messages can be identified initialize, configure, control,
start() : void and tear-down a component
as the producer of the log stop() : void
message. (e.g. an application’s
resources, a Device, or an
Application).

Page 93
Resource Interface
Advantages

Resource supports a set of behavior that enables

Application delegation and teardown and consistent
component deployment between ApplicationFactory
(during application instantiations) and DeviceManager
(during domain component deployment).
Resource is used by an HCI (or other domain management
clients) to configure an Application or Device within the
domain.
Makes it possible to have a generic HCI that could work for
all Applications and Devices.

Page 94
 ResourceFactory Interface
Modeled after the Factory design pattern
Provides a generic framework of operations for creating and destroying
Resources and obtaining a resource without knowing its identity

<<Interface>>
Reso urceFactory
identifier : string

createResource(resourceId : in string, qualifiers : in Properties) : Resource

releaseResource(resourceId : in string) : void
shutdown() : void

Resource Factory Can Create Resources of Different Types

• The resource’s Software Package Descriptor in the Domain Profile specifies properties dictating the
resource type.
• These properties are passed in as “qualifiers” to createResource(), dictating the type of resource to be
created.

Page 95
ResourceFactory Resource
Creation and Destruction

Creation
– If the Resource has not yet been created, it is created in the
same process space as the ResouceFactory.
– If the Resource has already been created, its reference count is
incremented and a copy of it is returned.
Destruction
– If the specified Resource’s reference count is greater than one,
it is decremented.
– Otherwise, the specified Resource is torn down.

Page 96
ResourceFactory Interface
Advantages

The reference counting feature of the ResourceFactory is

beneficial for managing Resources that are used by
multiple applications.
Eliminates the constant redeployment of the shared
components across application boundaries.

Page 97
Implementation of a
ResourceFactory is Optional
An application is not required to use ResourceFactories to
obtain, create, or tear down resources.
The application’s Software Profile specifies which
application components require ResourceFactories.
– That is,
ƒ for which application’s components does the CF ApplicationFactory
create and use a ResourceFactory (instead of directly executing the
application’s component’s entry point) during instantiation of the
application, and correspondingly,
ƒ for which application components does the CF Application interface
use a ResourceFactory to destroy the application component,
(instead of directly terminating the component’s running task or
process).

Page 98
 Base Application Interfaces Model A
Component’s Maturity Cycle

Started
start stop

Startable initialize releaseObject

configure (may also be required)

Initializeable construct destroy

Page 99
CF Framework Control
Interfaces
 Definition of “Domain” in the
CF Problem Space
Abstraction of a computing node that
• Allows the control and monitoring of node
resources (i.e. CPU, processes, memory, file systems),
• Implements the OE,
• Executes a DeviceManager, and
• Executes installed OE and CF services (CORBA
Provides instances of aggregated objects
Naming Service, Event Service, FileSystem, Log
(get X, add X, remove X)
Service, etc.).

Node Domain SW Application Instance

0..n 0..n
• IDM Event Channel - Keeps Domain
aware of Domain Changes
• ODM Event Channel - Keeps Domain
clients aware of Domain Changes +2..n
1 0..n
Event Channel FileManager SW Application

Page 101
 How does the CF Domain
Get “Created”?
Each node and its resources are created (i.e. OS booted, file
systems created, installed OE and CF services started
(CORBA Naming Service, Event Service, FileSystem, Log
Service), DeviceManager representing the Node created,
DeviceManager components (devices, services, additional The entity in charge of
file systems, etc.) created and deployed on the Node. managing the domain is created.

Node Domain

+2..n
1
Event Channel FileManager

Page 102
Services Provided by the
CF Domain
Deploying and removing a node’s components to/from Retrieving the domain’s nodes
the domain (i.e. registering and un-registering a (DeviceManagers), software
DeviceManager along with its devices and services applications, and software application
to/from the domain) instances.

Node Domain SW Application Instance

0..n 0..n

Creating/controlling/terminating
sw application instances.
+2..n
1 0..n
Event Channel FileManager SW Application

Registering/un-registering Installing/uninstalling
to/from the domain event application software to/from
channels. the domain.

Page 103
CF Domain Services are Provided by the
following Framework Control Interface
Groupings

Base Device
Interfaces

Domain Management
Device Management Interfaces
Interfaces

Page 104
 CF Domain Services are Mapped to the
following Framework
Application
Control Interfaces Instantiation Interface

Application
Configuration/
Control/
Termination
Interface

Base Device
Interfaces
Domain Component
Node Component Deployment/Removal &
Deployment/Removal Application
Interface Installation/Uninstallation
Interface
Page 105
CF Framework Control
Base Device Interfaces
 CF Base Device Interfaces
Defined by CF requirements, implemented by application developers.
Framework for a device’s software
profile attribute, state management Framework of operations for
and status attributes, and capacity adding/removing devices to/from a
allocation/deallocation operations device capable of an aggregate
relationship
Framework of operations for
loading/unloading software modules
onto a device processor’s memory

Framework of operations for

executing/terminating
processes/threads on a device

Framework of attributes and unimplemented operations

representing the functional abstraction of a logical device
(zero or more hardware devices).

Page 107
 Device Interface
<<Interface>> <<Interface>> <<Interface>> <<Interface>>
PortSupplier LifeCycle PropertySet TestableObject

Basic definition of all Logical

Devices in a system.
as managed resources within the system.
State Management and Status Attributes

<<Interface>>
– Devices have states as they are viewed

Based on X.731 OSI State Management

Resource Logical Device - an abstraction of

0 or more hardware devices.
Since it’s a Resource, it can be
created, controlled, and
<<Interface>> terminated like a Resource.
Device
adminState : AdminTypeLOCKED, UNLOCKED, SHUTTING_DOWN Software Profile attribute – Each
compositeDevice : AggregateDevice device has a Software Package
label : string Descriptor (SPD) in the Domain
operationalState : OperationalType ENABLED, DISABLED
softwareProfile : string Profile that defines the logical
Device capabilities
Functions.

usageState : UsageType IDLE, ACTIVE, BUSY

(data/command uses and provides
allocateCapacity(capacities : in Properties) : boolean
deallocateCapacity(capacities : in Properties) : void
ports, configure/query properties,
capacity properties, status
Implementation depends on the device’s properties, etc.).
capacity model. Page 108
Device Interface
Advantages
The use of the Domain Profile Software Profile Descriptor allows a
generic HMI to be written to interface with any vendor’s Device and
to be used by a CF DomainManager and ApplicationFactory for
deployment of components onto devices.
Since the Device interface merely provides an abstraction of hardware,
it may be the case that many Devices can exist per physical
hardware element.
– A device such as a programmable modem could present itself as both a
Code Division Multi-Access (CDMA) and a Time Division Multiple Access
(TDMA) modem Device simultaneously.
This abstraction also allows physical devices to be emulated.
– For example, a Device such as a printer could be emulated on a
general-purpose processor. Instead of providing a printed page of the
information sent to it, the printer Device could present the page
graphically on a display.

Page 109
 LoadableDevice Interface
• Extends the Device interface by The load module file name and load
type are located in the device
adding software loading and component’s Software Package
unloading behavior for a particular Descriptor in the Domain Profile.
device.
• Implementation is OS-dependent. <<Interface>> Possible Load Types
Device KERNEL_MODULE
DRIVER – Device Driver
SHARED_LIBRARY – Dynamic
Examples: Linking
modem, FPGA EXECUTABLE – Main POSIX Process

<<Interface>>
LoadableDevice

load(fs : in FileSystem, fileName : in string, loadKind : in LoadType) : void

unload(fileName : in string) : void

Page 110
 ExecutableDevice
Interface
• Extends the LoadableDevice
interface by adding execute and
terminate behavior for a device.
• Used for devices with an OS (e.g.
VxWorks, LynxWorks, Linux,
Integrity, etc.) that supports <<Interface>>
creation of threads/processes. LoadableDevice Examples:
• Implementation is OS- General Purpose Processors
dependent. (Intel, PowerPC)

<<Interface>>
ExecutableDevice

execute(name : in string, options : in Properties, parameters : in Properties) : ProcessID_Type

terminate(processId : in ProcessID_Type) : void

Page 111
 ExecutableDevice
Interface (cont.)
Name of a function (thread) or • Id/value pairs converted to (argc,
file (process), depending on the argv) format.
OS. • Some are SCA-defined required
parameters (e.g.
DEVICE_MANAGER_IOR,
• Optional stack size and NAMING_SERVICE_IOR, etc.).
priority <<Interface>> • Some are optional user-specified
• Specified in the LoadableDevice parameters specific to the executable
executable component’s component’s implementation.
SPD in Domain Profile (Specified in the component’s SPD in
the Domain Profile.)

<<Interface>>
ExecutableDevice

execute(name : in string, options : in Properties, parameters : in Properties) : ProcessID_Type

terminate(processId : in ProcessID_Type) : void

Page 112
 AggregateDevice Interface
<<Interface>> An aggregated logical Device adds
itself to a composite Device. An
Device
aggregate Device uses this
This Interface is provided by a interface to add or remove itself
Device through a "provides port" from the composite Device when it
0..n
named “CompositeDevice” for any is being created or torn-down.
Device that is capable of an
aggregate relationship. 0..1
List of Devices that <<Interface>>
have been added to AggregateDevice
this Device through
the addDevice( ) devices : DeviceSequence
Examples:
operation and have
not yet been addDevice(associatedDevice : in Device) : void y INFOSEC
removed through removeDevice(associatedDevice : in Device) : void Device with “n”
the removeDevice( ) crypto channel
operation. Devices
y I/O Device with
“n” ports
Page 113
CF Framework Control
Interface for
Node Component
Deployment and Removal
 Node Component Deployment
and Removal Interface
Responsible for
creation of logical
Devices, and
launching service
applications on
these logical
Devices during a
CF Node startup,
and deploying and
removing these
logical Devices and
services to/from
the CF Domain,
during CF startup,
shutdown, or
dynamically at run-
time.

Page 115
What the DeviceManager
Represents in the CF Domain
A given system is composed of a set of nodes (CORBA-
capable boards) with persistent components deployed and
running on them.

Each node is associated with a DeviceManager. And each

node is viewed as an independent object within the system.

Node Domain SW Application Instance

0..n 0..n

+2..n
1 0..n
Event Channel FileManager SW Application

Page 116
DeviceManager’s Job

The DeviceManager manages a set of persistent

components for a given node within a domain.
– Logical Devices and services (e.g., Log, Event
Service, Naming Service, domain-specific services
and devices).
It manages these persistent components by
– Starting them up as specified in the Domain Profile file, known
as the Device Configuration Descriptor (DCD) file, AKA
DeviceManager Profile
– Provides operations for deploying them to the CF domain as
directed by the DCD during DeviceManager startup,
– And removing them from the CF domain upon DeviceManager
shutdown.

Page 117
DeviceManager’s Job (cont.)

During startup of Logical Devices and service components, the

DeviceManager supplies a set of well-defined executable
parameters to the component to promote portability of logical
Devices and services and consistent behavior from one SCA-
complaint system to another SCA-complaint system that hosts these
components.
– DEVICE_MGR_IOR
– PROFILE_NAME
– DEVICE_ID
– DEVICE_LABEL
– Composite_DEVICE_IOR
– SERVICE_NAME
– Component-specific startup parameters defined in the component’s
Software Profile (SPD) processed by DeviceManager

Page 118
DeviceManager Interface
<<Interface>> <<Interface>>
PortSupplier PropertySet

<<Interface>>
DeviceManager
deviceConfigurationProfile : string
fileSys : FileSystem
identifier : string
label : string
registeredDevices : DeviceSequence
registeredServices : ServiceSequence

configure(configProperties : in Properties) : void

getComponentImplementationId(componentInstantiationId : in string) : string
getPort(name : in string) : Object
query(configProperties : inout Properties) : void
registerDevice(registeringDevice : in Device) : void
registerService(registeringService : in Object, name : in string) : void
shutdown() : void
unregisterDevice(registeredDevice : in Device) : void
unregisterService(registeredService : in Object, name : in string) : void

Page 119
Elements of a
DeviceManager Node
<<Interface>> <<Interface>>
PortSupplier PropertySet

<<Interface>>
DeviceManager

registeredDevices : DeviceSequence
registeredServices : ServiceSequence

As nodes are removed or added to the system

(DomainManager), the set of elements belonging
to a node are easily identified by the attributes of
the corresponding DeviceManager interface.

Page 120
DeviceManager’s
FileSystem
<<Interface>> <<Interface>>
PortSupplier PropertySet

<<Interface>>
DeviceManager

fileSys : FileSystem

A node usually has some file system associated with it,

represented by the DeviceManager filesystem attribute.
The underlying implementation for a file system may be
implemented as a FileManager when the node consists
of many file systems. This file manager is given out as a
file system since the FileManager interface is derived
from the FileSystem interface. Covered later.

Page 121
Registration of Logical Devices
and Services with DeviceManager
<<Interface>> <<Interface>>
PortSupplier PropertySet

<<Interface>>
DeviceManager

Deployed logical Devices and services created by the

DeviceManager, register/unregister themselves to/from their
DeviceManager via the register/unregister Device/Service
operations. If the DeviceManager has already been deployed
to the Domain, the DeviceManager will in turn deploy/remove
these components to/from the Domain, using the
DomainManager interface.
These operations can also be used to dynamically add/remove
devices/services from a DeviceManager after startup, during
CF’s lifetime.
registerDevice(registeringDevice : in Device) : void
registerService(registeringService : in Object, name : in string) : void
unregisterDevice(registeredDevice : in Device) : void
unregisterService(registeredService : in Object, name : in string) : void

Page 122
DeviceManager
Configure/Query Properties
<<Interface>> <<Interface>>
PortSupplier PropertySet

<<Interface>>
DeviceManager

The DeviceManager interface inherits the

PropertySet interface in order to manage
implementation properties that are described in its
Software Package Descriptor (SPD) file and to
change its producer log level properties.

Page 123
Services for
DeviceManager’s Use
<<Interface>> <<Interface>>
PortSupplier PropertySet

<<Interface>>
DeviceManager

The PortSupplier interface inherited by

the DeviceManager interface is used to
connect services (e.g., Log) to the
DeviceManager.

Page 124
CF Framework Control
Interface for Domain
Component Deployment and
Removal
&
Application Installation and
Un-installation
 DomainManager’s Job
To support the instantiation and tear-down of First, it provides the
means for
applications in the CF domain, the DomainManager
deployment,
provides 2 kinds of services: interconnection,
disconnection, and
removal of
persistent
components to/from
the CF domain
during
registration/unregis
tration of
DeviceManagers
and their devices,
services, with/from
DomainManager.

Page 126
DomainManager Provides
Operations for…
<<Interface>>
PropertySet Registration/unregistration
of DeviceManager’s, devices
and services to/from the CF
domain.
<<Interface>>
DomainManager
applicationFactories : ApplicationFactorySequence
applications : ApplicationSequence
deviceManagers : DeviceManagerSequence
domainManagerProfile : string
fileMgr : CF::FileManager
identifier : string

installApplication(profileFileName : in string) : void

registerDevice(registeringDevice : in Device, registeredDeviceMgr : in DeviceManager) : void
registerDeviceManager(deviceMgr : in DeviceManager) : void
registerService(registeringService : in Object, registeredDeviceMgr : in DeviceManager, name : in string) : void
registerWithEventChannel(registeringObject : in Object, registeringId : in string, eventChannelName : in string) : void
uninstallApplication(applicationId : in string) : void
unregisterDevice(unregisteringDevice : in Device) : void
unregisterDeviceManager(deviceMgr : in DeviceManager) : void
unregisterFromEventChannel(unregisteringId : in string, eventChannelName : in string) : void
unregisterService(unregisteringService : in Object, name : in string) : void

Page 127
DomainManager’s Job (cont.)

…Next, it services Domain

Application installation and un-
installation requests by
creating/destroying a corresponding
ApplicationFactory for each
installed Application.
Page 128
DomainManager Provides
Operations for…
<<Interface>>
PropertySet Installation and
uninstallation of software
applications to/from the CF
domain.
<<Interface>>
DomainManager
applicationFactories : ApplicationFactorySequence
applications : ApplicationSequence
deviceManagers : DeviceManagerSequence
domainManagerProfile : string
fileMgr : CF::FileManager
identifier : string

installApplication(profileFileName : in string) : void

registerDevice(registeringDevice : in Device, registeredDeviceMgr : in DeviceManager) : void
registerDeviceManager(deviceMgr : in DeviceManager) : void
registerService(registeringService : in Object, registeredDeviceMgr : in DeviceManager, name : in string) : void
registerWithEventChannel(registeringObject : in Object, registeringId : in string, eventChannelName : in string) : void
uninstallApplication(applicationId : in string) : void
unregisterDevice(unregisteringDevice : in Device) : void
unregisterDeviceManager(deviceMgr : in DeviceManager) : void
unregisterFromEventChannel(unregisteringId : in string, eventChannelName : in string) : void
unregisterService(unregisteringService : in Object, name : in string) : void

Page 129
DomainManager Provides
Operations for…
<<Interface>>
PropertySet Registration/unregistration
of producer(s)/consumer(s)
to/from domain event
channels.
<<Interface>>
DomainManager
applicationFactories : ApplicationFactorySequence
applications : ApplicationSequence
deviceManagers : DeviceManagerSequence
domainManagerProfile : string
fileMgr : CF::FileManager
identifier : string

installApplication(profileFileName : in string) : void

registerDevice(registeringDevice : in Device, registeredDeviceMgr : in DeviceManager) : void
registerDeviceManager(deviceMgr : in DeviceManager) : void
registerService(registeringService : in Object, registeredDeviceMgr : in DeviceManager, name : in string) : void
registerWithEventChannel(registeringObject : in Object, registeringId : in string, eventChannelName : in string) : void
uninstallApplication(applicationId : in string) : void
unregisterDevice(unregisteringDevice : in Device) : void
unregisterDeviceManager(deviceMgr : in DeviceManager) : void
unregisterFromEventChannel(unregisteringId : in string, eventChannelName : in string) : void
unregisterService(unregisteringService : in Object, name : in string) : void

Page 130
DomainManager Provides
Access to the Domain’s…
<<Interface>>
PropertySet

<<Interface>>
DomainManager • Installed Applications
applicationFactories : ApplicationFactorySequence • Instantiated Applications
applications : ApplicationSequence
deviceManagers : DeviceManagerSequence
• Registered DeviceManagers
domainManagerProfile : string (and their devices and services)
fileMgr : CF::FileManager
identifier : string
• FileSystem
installApplication(profileFileName : in string) : void
registerDevice(registeringDevice : in Device, registeredDeviceMgr : in DeviceManager) : void
registerDeviceManager(deviceMgr : in DeviceManager) : void
registerService(registeringService : in Object, registeredDeviceMgr : in DeviceManager, name : in string) : void
registerWithEventChannel(registeringObject : in Object, registeringId : in string, eventChannelName : in string) : void
uninstallApplication(applicationId : in string) : void
unregisterDevice(unregisteringDevice : in Device) : void
unregisterDeviceManager(deviceMgr : in DeviceManager) : void
unregisterFromEventChannel(unregisteringId : in string, eventChannelName : in string) : void
unregisterService(unregisteringService : in Object, name : in string) : void

Page 131
CF Framework Control
Application Creation Interface
Installation of an Application…
…results in creation of a
corresponding
ApplicationFactory for
that type of Application.

Page 133
 Application Creation
Interface
Based on user’s request,
the ApplicationFactory
creates a CORBA object
implementing the
Application interface for
each Application created.

0 .. n

The created ApplicationFactory

provides the interface to request the
instantiation of a specific type of
Application in the domain, based on the
Application’s software profile provided
to DomainManager during application
installation. Page 134
 ApplicationFactory
Interface
Based on the Domain Profile, creates instances of software applications of a specific
type by:
• Allocating software (Resources) to hardware (Devices)
– Allocating capacities against Devices
• Connecting Resources that make up an Application
• Performing initial configuration on these Resources

<<Interface>>
ApplicationFactory
identifier : string
name : string
softwareProfile : string

create(name : in string,
initConfiguration : in Properties,
deviceAssignments : in DeviceAssignmentSequence) : Application

Page 135
 ApplicationFactory
Interface (cont.)
User-friendly name for the application type, identifier, and the software
profile (Domain Profile Software Assembly Descriptor (SAD)) used for
creating applications of that type.
<<Interface>>
ApplicationFactory
identifier : string SAD ID – Used to identify the corresponding
name : string ApplicationFactory when logging messages or
sending events to the Outgoing Domain
softwareProfile : string Management Event Channel.

create(name : in string,
initConfiguration : in Properties,
deviceAssignments : in DeviceAssignmentSequence) : Application

The create operation allows the user to request the creation of

an application, provide it with pre-selected devices, and specify
its configuration properties.

Page 136
 How an Application Instance
is Brought into Existence
• UI asks for all installed Apps
(ApplicationFactories). Determines applicable Device(s)
• AppFactory is chosen & issued a create (). on which to load application code
defined in Domain Profile.

CF::Application is
returned – providing
proxy interface to the
Assembly Controller of
created Resources.

Resources are then

initialized, and configured.

Page 137
ApplicationFactory
Interface Advantages
The ApplicationFactory provides an interface to request the creation of
a specific type of application in the domain.
– This abstraction allows a user interface to manipulate a group of
application types as objects.
There is one ApplicationFactory object for each type of application and
one implementation for all ApplicationFactory objects.
– Each ApplicationFactory object has its own instance variables based
upon the same servant class definition and therefore is its own unique
instance.
The ApplicationFactory interface provides a standard interface for
creating applications within the domain, and one common
implementation within the domain for creating applications.
– Each application developer doesn’t have to develop code to parse their
own software profiles and retrieve domain profile (devices, etc.) to
create their application within a domain.

Page 138
CF Framework Control
Application Configuration,
Control and Termination
Interface
 CF Application
Instantiation Interfaces
…provides the means to
manage an instantiated
application’s lifecycle,
state, and behavior.

0 .. n

When the
ApplicationFactory
instantiates an Application,
it returns the proxy for its
implementation which…
Page 140
 Application Interface – A
Specialized Resource
Since users need to control the
lifespan of applications,
configure them, and control
From an end-user perspective, <<Interface>> their behavior, the Application
software applications are the Resource interface is derived from the
primary functional element of a Resource interface, so that it
system. can provides the necessary
operations for managing
An Application has application lifecycle, state, and
characteristics very similar to a <<Interface>> behavior.
Resource. For example, an Application
application has properties and The implementation of an
communicates through ports. Application is comprised of a
set of Resource component
implementations and their
interconnections.

Page 141
 Application Interface – A Proxy
for an Instantiated SW Assembly
The Application delegates its
inherited Resource
operations to a Resource
<<Interface>>
component that has been Resource
identified as the “assembly
controller for the software
assembly”.

Since the Application <<Interface>>

Application
interface is derived from
Resource and an assembly
controller is also a Resource,
this makes the delegation
very simple and elegant.

Page 142
 What is an Assembly
Controller?
<<Interface>> <<Interface>>
Port Resource
identifier : string • Acts like the POC for the
connectPort() CF to communicate with the
disconnectPort() start() Application.
stop()
• All applications are
required to have one
<<use>>
component that acts like an
assembly controller.
<<Implementation>>
AssemblyControl ler
• Identified in the
Application’s Software
Assembly Descriptor file in
the Domain Profile.
Page 143
Assembly Controller
Example
Connection of Assembly Controller and
other Application Components to each
other, and outside entities (e.g. UI,
Device(s), other application’s via ports.
More on this later.

Page 144
 Providing Access to an
Application’s Ports
The Application’s ports provide the
capability of connecting the <<Interface>>
Application up to other components PortSupplier
such as an Application.
getPort()
The ports can also be used to provide
additional command/control and/or
status interfaces for an Application.
<<Interface>>
The ports for an Application are Resource
flexible allowing developers to
determine which of their
Application’s components’ ports
should be made visible via the
Application’s software profile <<Interface>>
definition. Appli cation

Page 145
Application Interface

<<Interface>>
Application
identifier : string
componentDevices : CF::DeviceAssignmentSequence
componentImplementations : CF::Application::ComponentElementSequence
componentNamingContexts : CF::Application::ComponentElementSequence
componentProcessIds : CF::Application::ComponentProcessIdSequence
name : string
profile : string

Name of the Domain Profile file (Software Assembly

Descriptor (SAD)), that describes the Application’s internal
structure and the characteristics of the software assembly.

Page 146
Application Interface (cont.)

<<Interface>>
Application
identifier : string
componentDevices : CF::DeviceAssignmentSequence
componentImplementations : CF::Application::ComponentElementSequence
componentNamingContexts : CF::Application::ComponentElementSequence
componentProcessIds : CF::Application::ComponentProcessIdSequence
name : string
profile : string

List of object references of all Logical Device(s) on which

Application’s component’s are loaded and/or are running.
Used by Application for unloading and terminating
component modules and processes during Application tear-
down.
Page 147
Application Interface (cont.)

<<Interface>>
Application
identifier : string
componentDevices : CF::DeviceAssignmentSequence
componentImplementations : CF::Application::ComponentElementSequence
componentNamingContexts : CF::Application::ComponentElementSequence
componentProcessIds : CF::Application::ComponentProcessIdSequence
name : string
profile : string

List of identifiers for chosen (running) component

implementations from the Application’s software profile for
each created component . More on this later during the
Domain Profile lecture.

Page 148
Application Interface (cont.)

<<Interface>>
Application
identifier : string
componentDevices : CF::DeviceAssignmentSequence
componentImplementations : CF::Application::ComponentElementSequence
componentNamingContexts : CF::Application::ComponentElementSequence
componentProcessIds : CF::Application::ComponentProcessIdSequence
name : string
profile : string

List of all Naming Service Naming Contexts to which Application

components are bound. When a component is created, it binds itself
to the Naming Service under a predefined naming context defined
in the Application’s software profile. During Application tear-
down, the component’s object ref along with this naming context
are removed from the Naming Service.
Page 149
Application Interface (cont.)

<<Interface>>
Application
identifier : string
componentDevices : CF::DeviceAssignmentSequence
componentImplementations : CF::Application::ComponentElementSequence
componentNamingContexts : CF::Application::ComponentElementSequence
componentProcessIds : CF::Application::ComponentProcessIdSequence
name : string
profile : string

List of identifiers for all running processes or tasks for all

Application components. Used for terminating these
processes or tasks during Application tear-down.

Page 150
Application Interface
Advantages

The Application interface provides a standard

interface for all applications within the domain,
and one common implementation within the
domain for all applications.
Application developers don’t have to develop code
to tear down their application and to behave
according to the Application’s software profile
(SAD).
Having a generic Application abstraction supports
general purpose user interface components for
controlling a system.

Page 151
CF File Service Interfaces
CF File Services Interfaces
Provides the ability to
read and write files
within a SCA-
compliant distributed Defines CORBA
file system. operations that
enable remote access
to a physical file
system.

Appearing as a single
FileSystem, provides
access to multiple
distributed file systems,
whose file storage may
span multiple physical
file systems (AKA a Used by CF clients for all file accesses.
federated file system).

Page 153
File Interface
• Provides access to files within the system
• Allows access across processor boundaries (distributed
FileSystems)

<<Interface>>
File
fileName : string
filePoint er : unsigned long

close() : void
read(data : out OctetSequence, length : in unsigned long) : void
setFilePoint er(filePoint er : in unsigned long) : void
sizeOf() : unsigned long
write(data : in OctetSequence) : void

Page 154
FileSystem Interface
Allows creation, deletion, copying of files

<<Interface>>
FileSystem

copy(sourceFileName : in string, destinationFileName : in string) : void

create(fileName : in string) : File
exists(fileName : in string) : boolean
list(pattern : in string) : FileInformationSequence
mkdir(directoryName : in string) : void
open(fileName : in string, read_Only : in boolean) : File
query(fileSystemProperties : inout Properties) : void
remove(fileName : in string) : void
rmdir(directoryName : in string) : void

Page 155
 FileManager Interface

FileManager inherits from

FileSystem, as it appears as a FileManager uses FileSystem,
<<Int erface>>
single FileSystem to clients, FileSystem as it delegates all FileSystem
even though it may be operations to the correct
managing multiple distributed FileSystem.
FileSystems.
<<Interface>>
FileManager

getMounts() : MountSequence
mount(mountPoint : in string, file_System : in FileSystem) : void
unmount(mountPoint : in string) : void

Page 156
CF Domain Profile
Domain Profile

A set of files that express the packaging and

deployment of SCA-complaint components.
– Specific characteristics of software components or
hardware devices.
– Interfaces, functional capabilities, logical location,
interconnections, inter-dependencies, and other
pertinent properties and parameters.
– e.g. Description of applications, startup requirements of
devices, etc.

Page 158
Defined in XML and Based
on XML DTDs

Defined in eXtensible Markup Language (XML)

format.
Based upon SCA-defined XML Document Type
Definitions (DTDs).
– A DTD defines the meaning and compliant syntax for
a XML file.

Page 159
Based on OMG CORBA
Components Specification
Based upon the OMG's draft CORBA Components
specification (orbos/99-07-01).
Customized from the OMG CORBA Component
Specification.
– Addition, or customization of existing elements to better address
the needs of an SCA-compliant system.
– Elimination of unneeded elements in order to reduce the
associated XML parsing and aid in XML file content validation.
– Advantageous, as it builds upon work already completed by
OMG and does not duplicate effort.

Page 160
Domain Profile Files
Software Package Descriptor (SPD)
– Describes a component’s (CORBA and non-CORBA)
implementation(s).
Property File (PRF)
– Describes properties for a component.
Software Component Descriptor (SCD)
– Describes a CORBA component’s characteristics.
Software Assembly Descriptor (SAD)
– Describes an application’s deployment characteristics.
Device Configuration Descriptor (DCD)
– Describes configuration characteristics for a DeviceManager.

Page 161
Domain Profile Files (cont.)

DomainManager Configuration Descriptor (DMD)

– Describes configuration characteristics for a DomainManager.
Device Package Descriptor (DPD)
– Identifies a class of hardware device and its characteristics.
Profile Descriptor
– Describes a type of file (SAD, SPD, DCD, DMD) along with the
file name.

Page 162
 Domain Profile XML DTD
Relationships
0 or more DeviceManagers, Domain Profile
0 or more ApplicationFactories,
deploying persistent representing installed, to be
components to the CF instantiated, or already running
domain applications in the domain
0..n 1 DomainManager 0..n
1
<<DTDElement>> <<DTDElement>>
Device Configuration D escriptor DomainManager
Configuration Descriptor Software Assembly Descriptor
DCD SAD
DMD
1
1
1
SoftwareProfile
Software Profile

1..n
<<DTDElement>> A component’s 1..n 1
Profile Descriptor
(CORBA and non- <<DTDElement>> SoftwareProfile <<DTDElement>>
Software Package Descriptor 1 Profile Descriptor
CORBA)
implementations SPD
A component’s A CORBA component’s
properties characteristics (e.g. “use” &
0..1
0..n “provides” ports.
A hardware 0..n

device class & its <<DTDElement>>

Device Package Descriptor
0..n
<<DTDElement>> <<DTDElement>>
Properties Descriptor Software Component Descriptor
characteristics DPD PRF
0..n
SCD
Both DCD and SAD are assembly types that deploy component implementations.
Page 163
Software Package
Descriptor (SPD)
Based on CORBA Components Software Package
Descriptor.
Used to describe any software component.
– CORBA or non-CORBA.
An application’s software profile (Software Assembly
Descriptor), contains one SPD for each software
component of that application.

Page 164
 SPD Major Elements
<<DTDElement>>
A Software package softpkg Local file name of the SCD file
id : ID used to describe interface
may contain multiple name : CDATA
information for the component
type : (sca_compliant | sca_non_compliant) = sca_compliant
implementations (for version : CDATA being delivered to the system.
different hardware) using
the same properties and Any “uses” relationship this
Software Component <<DTDSequenceGroup>>
softpkg_grp component has with a device in
Descriptor (SCD). (from softpkg) the system. Will contain all
allocation properties for that
device, indicating capacities
needed from that Device by the
software component.
0..1 1..n 0..1 0..n
{4} {2} {5}
{7}
<<DTDElement>> <<DTDElement>> <<DTDElement>>
<<DTDElement>>
propertyfile author descriptor
usesdevice
type : CDATA name : CDATA
id : ID
type : CDATA

0..1 1..n 0..1

{1} {3}
{6}
<<DTDElementPCDATA>> <<DTDElement>> <<DTDElementPCDATA>>
title implementation description
id : ID
aepcompliance : (aep_compliant | aep_non_compliant) = aep_compliant
Page 165
 SPD implementation Element
<<DT DEl em ent>>
Local file name of the i d : ID
i m pl ementati on Module’s Load Type
load module, with a aepcompl i ance : (aep_compl i ant | aep_non_compl i ant) = aep_com pl i ant
• “Executable”: load &
possible entry point execute
• “KernelModule” &
task name, for this <<DT DSequenceGroup>>

“Driver”: load only

i m pl ementati on_grp
(from i mpl em entati on)
specific • “SharedLibrary”: load
implementation of the only, or load an execute
software component. depending on existence of a
code entry point
0..1 0..1
0..1 0..n {7}
{1}
{2} {3} {9} <<DT DEl em entEMPT Y>>
<<DT DEl em entPCDAT A>> runti m e
descri pti on <<DT DEl em ent>> <<DT DEl em ent>> <<DT DEl em ent>>
propertyfi l e code usesdevi ce name : CDAT A
i d : ID versi on : CDAT A
type : CDAT A type : CDAT A
type : CDAT A

0..1 0..1 1..n 0..1

{4} {5} {8} {6}
<<DT DEl em entEMPT Y>> <<DT DEl em entEMPT Y>> <<DT DChoi ceGroup>> <<DT DEl em entEMPT Y>>
compi l er programm i ngl anguage i m pl ementati on_grp_grp humanl anguage
name : CDAT A name : CDAT A (from i mpl em entati on_grp)
name : CDAT A
versi on : CDAT A versi on : CDAT A

<<DT DEl em entEMPT Y>> <<DT DEl em entEMPT Y>> <<DT DEl em ent>>
os processor dependency
name : CDAT A name : CDAT A type : CDAT A
versi on : CDAT A

Page 166
Properties Descriptor

Derived from the CORBA Components properties

element.
Contains information about properties applicable
to a software package or a device package.
It is a sequence of 1 or more properties, where…
Each property is of a particular property type and
property kind.

Page 167
Properties Descriptor
Property Types
<<DTDElement>>
properties

<<DTDSequenceGroup>>
properties_grp
(from properties)

0..1 1..n
{1} {2}
<<DTDElementPCDATA>> <<DTDChoiceGroup>>
description properties_grp_grp
(from properties_grp)

Frequency, Scan Frequency Commanded Date Structure Preset Data

Power Level List Level BIT

<<DTDElement>> <<DTDElement>> <<DTDElement>> <<DTDElement>> <<DTDElement>>

simple simplesequence test struct structsequence

Page 168
 Properties Descriptor
Property Kinds
<<DTDElement>>
Capacity type properties for simple
logical Devices id : ID
type : (boolean | char | double | float | short | long | objref | octet | string | ulong | ushort)
Configuration or query name : CDATA
mode : (readonly | readwrite | writeonly) = readwrite
properties for a
component
Test properties for a <<DTDSequenceGroup>>
ResourceFactory create
simple_grp
component (from simple) options parameters
User defined execute
parameters for main
0..1
{1} programs 0..1
{2}
<<DTDElementPCDATA>> <<DTDElementPCDATA>>
description value

0..1
0..1 {4}
0..1
{3} <<DTDElementEMPT Y>> {5}
<<DTDElementPCDATA>> range
<<DTDElement>>
units min : CDATA enumerations
0..n max : CDATA 0..1

{6} {7}
<<DTDElementEMPT Y>> <<DTDElementEMPT Y>>
kind action
kindtype : (allocation | configure | test | execparam | factoryparam) = configure type : (eq | ne | gt | lt | ge | le | external) = external

Page 169
Software Component
Descriptor (SCD)
Based on the CORBA Component Descriptor (CCD) file
definition.
– interfaces, uses port, provides port, supporting interfaces.
Provides the means for a component to describe its
interfaces in two ways.
– Supporting interfaces which are IDL interfaces inherited by the
component IDL interface.
– Provides interfaces or “facets” - Distinct CORBA interfaces that
a component implementation supports in addition to the
component’s interface.

Page 170
 SCD Elements
The type of software component <<DTDElement>> The supported message ports
softwarecomponent for the component.
object, and hence, its
characteristics (e.g. resource,
device, resourcefactory, List of all interfaces that
<<DTDSequenceGroup>> the component, either
domainmanager, log, filesystem,
softwarecomponent_grp directly or through
filemanager, namingservice, (from softwarecomponent) inheritance, provides,
eventservice. uses, or supports.
{1} {6}
<<DTDElementPCDATA>> 0..1 <<DTDElement>>
corbaversion propertyfile
type : CDATA

{2} {3} {4} {5}

<<DTDElementEMPTY>> <<DTDElementPCDATA>> <<DTDElement>> <<DTDElement>>
componentrepid componenttype componentfeatures interfaces
repid : CDATA

Page 171
 SCD Supported Message
Ports Element

<<DTDElement>>
componentfeatures

Identifies an IDL interface <<DTDSequenceGroup>>

supported by the component. componentfeatures_grp
(from componentfeatures)

0..n
{1} {2}
<<DTDElementEMPTY>> <<DTDElement>> Interfaces
Refers to the supportsinterface ports
supported interface “provided” and/or
repid : CDATA
in the SCD supportsname : CDATA “used” by the
“interfaces” component.
element.

Page 172
 SCD Ports Element
A “Facet” – An independent
interface from the <<DTDElement>>
component’s main interface, ports
A CF Port interface type that
providing a specialized is to be connected to a
connectivity to the “provides” or
component. 0..n “supportinterfaces”
<<DTDChoiceGroup>> interface.
ports_grp
Each “uses” and (from ports)
“provides” port Each “uses” and
references its “provides” port
corresponding <<DTDElement>> <<DTDElement>> references its
interface (i.e. the provides uses corresponding
corresponding repid : CDATA repid : CDATA interface (i.e. the
SCD interface providesname : CDATA usesname : CDATA corresponding
element) by its id. SCD interface
element) by its id.

Page 173
Device Package Descriptor
(DPD)

Not derived from the CORBA Component

Specification.
Identifies a class of a hardware device along with
its properties.
– Typically used by an HCI application to display
information about the device(s) resident on an SCA-
compliant system.
Based on the SCA Hardware Architecture
definition.

Page 174
DPD Elements
<<DTDElement>>
devicepkg
id : ID
name : CDATA
version : CDATA

<<DTDSequenceGroup>>
devicepkg_grp
(from devicepkg)

0..1 1..n 0..1

{4} {1} {2} {3}
<<DTDElement>> <<DTDElementPCDATA>> <<DTDElement>> <<DTDElementPCDATA>>
hwdeviceregistration title author description
id : ID
name : CDATA
version : CDATA

Page 175
DPD Elements (cont.)
<<DTDElement>>
Device identification hwdeviceregistration
information, including the id : ID
name : CDATA
device name, device class, version : CDATA
manufacture, and model
number.
<<DTDSequenceGroup>>
hwdeviceregistration_grp
(from hwdeviceregistration)

{5} {6}
0..n
<<DTDElement>> <<DTDElement>>
deviceclass childhwdevice

0..1
{2} {4}
{1} {3}
<<DTDElementPCDATA>> <<DTDElement>> <<DTDElementPCDATA>> <<DTDElementPCDATA>>
description propertyfile manufacturer modelnumber
type : CDATA

Page 176
DPD Elements (cont.)

The DPD allows for … or in

<<DTDElement>>
composition device childhwdevice
multiple files (DPD can
definitions to be formed reference other DPDs).
up completely in one file
… <<DTDChoiceGroup>>
childhwdevice_grp
(from childhwdevice)

<<DTDElement>> <<DTDElement>>
hwdeviceregistration devicepkgref
id : ID type : CDATA
name : CDATA
version : CDATA

Page 177
Software Assembly
Descriptor (SAD)

Derived from the CORBA Component Assembly

Descriptor (CAD) file definition.
Describes what makes up an application, how to
create the application’s pieces, configure them,
and interconnect them.
Processed by CF::ApplicationFactory during
application instantiation.

Page 178
SAD Contents

Based on the CORBA Components Assembly

Descriptor concepts of component files,
partitioning, and connections, it describes:
– What component instances makeup an assembly.
– Which components are located together.
– How to find components (e.g., naming service).
– How to connect components together.

Page 179
SAD Contents (cont.)

The required identification of a component as the main

assembly controller.
– Simplifies the behavior of the CF Application that acts a proxy
for the assembly controller.
– By having a mandated assembly controller, the Application
proxy simply delegates its Resource operations to the assembly
controller Resource.
The optional visible ports for a software assembly.
– Allows the assembly to be treated like a component that can be
connected to for its data ports, or additional status and
command/control ports.

Page 180
 SAD Top-Level Elements
The local file names of the The main CF Resource for controlling
<<DTDElement>> the Assembly. The corresponding
SPDs of the 1..n software softwareassembly instantiated CF::Application delegates
components that make up the id : ID its Resource configure, query, start,
software assembly. name : CDATA stop, and runTest operations to this
Assembly Controller.
The deployment pattern of Provides the connection map between
the SAD components and the sw components in the assembly.
their components-to-hosts <<DTDSequenceGroup>>
relationships. softwareassembly_grp
Assembly’s visible
(from softwareassembly) Ports. Returned by
CF::Application
getPort ().
0..1 {6}
{1}
0..1
<<DTDElementPCDATA>> <<DTDElement>>
description externalports

0..1
{2} {3} {4} {5}
<<DTDElement>> <<DTDElement>> <<DTDElement>> <<DTDElement>>
componentfiles partitioning assemblycontroller connections

Page 181
 SAD Component Deployment
Pattern
<<DTDElement>>
Comprised of a grouping of
componentplacement one or more
<<DTDElement>>
componentplacement
partitioning
<<DTDSequenceGroup>>
elements, describing a group
componentplacement_grp of component instances that
(from componentplacement)
0..n are to be deployed together
1..n
<<DTDChoiceGroup>> (i.e collocated) on a single
{1} partitioning_grp
<<DTDElementEMPTY>>
{2}
<<DTDElement>>
host.
(from partitioning)
componentfileref componentinstantiation
refid : CDATA id : ID

<<DTDElement>> <<DTDElement>>
… different ways of componentplacement hostcollocation
instantiating the same id : ID
component. What name : CDATA
different ways? Why
do this?
Defines one or more deployments of a
component. Meaning…
Page 182
 SAD Component Deployment
Pattern (cont.)
Optional list of Optional means of finding
• Component-specific execute the component after it has
parameter properties used for <<DTDElement>>
been created:
component creation. componentinstantiation • Via a ResourceFactory, if
• ResourceFactory parameter id : ID it has been created by one.
properties used for creating the • Via the Naming Service, if
component via a ResourceFactory. the component is directed to
• Configuration properties used for <<DTDSequenceGroup>>
register itself with the
initial configuration of the componentinstantiation_grp Naming Service upon
component (from componentinstantiation) creation.

0..1 0..1 0..1

{1} {2} {3}
<<DTDElementPCDATA>> <<DTDElement>> <<DTDElement>>
usagename componentproperties findcomponent

Page 183
Device Configuration
Descriptor (DCD)

Derived from the Software Assembly Descriptor file

definition.
Processed by each DeviceManager and by DomainManager
upon DeviceManager registration with CF domain.
Provides a generic means of deploying persistent
components (logical Device(s) and services) to the CF
domain during each node (DeviceManager) startup.
Allows a System Administrator flexibility to decide what
nodes within the system services should be deployed on
and how many services should be within a system.

Page 184
 DCD Elements
DeviceManager SPD. Connections of
All components (logical Devices, <<DTDElement>> DeviceManager and/or DCD
services, others) to be started by the deviceconfiguration Logical Devices to domain
DeviceManager on the node id : ID services. Similar to SAD.
represented by DeviceManager. name : CDATA Processed by
Similar to SAD. DomainManager upon
Deployment pattern of DCD DeviceManager registration.
components and their
How the DeviceManager can
component-to-host <<DTDSequenceGroup>> obtain the DomainManager
relationships. Similar to deviceconfiguration_grp object reference.
SAD. (from deviceconfiguration)
{1} 0..1 {7}
<<DTDElementPCDATA>> <<DTDElement>>
description 0..1
filesystemnames
{2} {6}

<<DTDElement>> <<DTDElement>>
devicemanagersoftpkg 0..1 0..1 0..1 domainmanager

{3} {4} {5}

<<DTDElement>> <<DTDElement>> <<DTDElement>> Mounted FileSystem
componentfiles partitioning connections names for the
DeviceManager’s
FileManager.
Page 185
 DCD Component
Deployment Pattern
The DCD provides the flexibility A DCD Logical Device may be
of deploying a DCD component <<DTDElement>> aggregated by another DCD
componentplacement
either on a pre-determined Logical Device that has or has
General Purpose Processor not yet been deployed by
Device (in the absence of a DeviceManager. The
deployondevice element), or on a aggregated device may be
<<DTDSequenceGroup>>
DCD-specific Logical Device deployed only after its parent
componentplacement_grp
that is yet to be deployed by device has been deployed, as it
(from componentplacement)
DeviceManager, as specified by needs its parent device object
the deployondevice
{1}
element. reference.
{5}
1..n
<<DTDElementEMPTY>> <<DTDElement>>
componentfileref componentinstantiation
refid : CDATA 0..1 0..1 0..1 id : ID
{2} {3} {4}
<<DTDElementEMPTY>> <<DTDElementEMPTY>> <<DTDElement>>
deployondevice compositepartofdevice devicepkgfile
refid : CDATA refid : CDATA type : CDATA

Page 186
DomainManager
Configuration Descriptor
• Not based on CORBA
Component Specification. <<DTDElement>>
domainmanagerconfiguration
• Describes the
id : ID
DomainManager’s SPD and name : CDATA
services to be connected to
DomainManager for
DomainManagement
functions (DomainManager, <<DTDSequenceGroup>>
domainmanagerconfiguration_grp
ApplicationFactory, (from domainmanagerconfigurati on)
Application) use.
• No other concept of
domain management. 0..1
{1} {2} {3}
<<DTDElementPCDATA>> <<DTDElement>> <<DTDElement>>
description devicemanagersoftpkg services

Page 187
SCA Concept of Components
& Domain Profile File Types
Core Framework objects
responsible for installing,
DomainManager starting up and tearing down An application is
applications an "assembly" of 1..n
software components Part of XML-based
1 "Domain Profile"
1
0..n
0..n
ApplicationFactory <<create>> Application described by SW Assembly
1 1 Descriptor
+Proxy 1

1..n
Properties described by Properties SW Component described by SW Package
Descriptor 1 1 1..n 1 1 1 Descriptor

Types

Non-CORBA CORBA described by

Part of XML-based Component Component SW Component
"Domain Profile" 1 1 Descriptor

Types

Device Package described by Device Resource ResourceFactory

Descriptor 1 1 Implements CF Device,
Resource &

used to access a Provides 0..n 0..n

Consumer Port of a Producer Uses Port connection Provides Port provided by Producer
1 1..n 1..n 1
described by a "connectinterface"
element within the SAD Page 188
How Does CF Interact
with Application
Components?
Some Examples of…
Starting a node (DeviceManager)
- DeviceManager startup
- Creating persistent devices and services on that node (DeviceManager)
- Deploying persistent devices and services to the CF domain to service
domain application instantiations (DeviceManager and DomainManager)
Installing an application (DomainManager)
Retrieving the list of installed applications (DomainManager)
Creating an application (ApplicationFactory)
– Creating a single application component
– Connecting an application’s components together
Retrieving the list of running applications (DomainManager)
Communicating with one of those running applications (Application)

Page 190
 Node (DeviceManager)
Startup
DeviceManager Might Expect: 4: Register Default DCD Deploy-on Device
y DCD File System IOR 8: Start DCD Components
y DCD file name (Create and deploy DCD-specified components
y Default DCD Deploy-on Device IOR (devices and services) to the CF domain).
y DomainManager IOR

: FileManager

: DeviceManager 1: <<create>> : Client

2: <<create>>
3: Mount DCD 9: registerDeviceManager()
FileSystem

: XML Parser 5: <<create>> 7: <<create>>

(Port for connecting 1+
6: Parse DCD & Log Service(s)
: DomainManager
associated To DeviceManager.)
XML files : LogUsesPort
Page 191
 Node (DCD) Component
Creation
Iterative process, until all DCD
devices & services are created
y Those deployed on deploy-on device
y Those deployed on other DCD devices
y Those deployed as AggregateDevices
y Those deployed as aggregated devices
: Device
1: Start DCD
5.1: register
Components 5.1.1: initialize
Device() 5.1.2: configure()
: XML 2: Process DCD &
10: allocateCapacity()
Parser associated XML files 11: load()
12: execute()
5.1.1: initialize
: ExecutableDevice 5.1.2: configure()
: DeviceManager Service
: LoadableDevice
: Deploy-on Device 5.1: registerService()
3: allocateCapacity()
4: load()
5: execute()
Page 192
 DCD Component (Device/Service)
Deployment to CF Domain
Domain
: DeviceManager Finder

2: get: 13: Add registered ODM Event

registered devices, services & event Channel
registered services, 1: Self channels
: FileManager 15: Notify of successful
file system, DCD register
7: getPort() domain object addition

14: log : Log

Domain 3: mount() DeviceManager
Profile registration 11: <<create>>
: DomainManager results 12: connect all suppliers and
4: add DevMgr DCD consumers to Domain Event
Profile channel(s)
Event
: Device 8: getPort() Channel
6: getPort()
10: connectPort()
5: getPort()
9: resolve()
Other Domain Device or
DeviceMgr or Service
Service
Naming : Port
Service
Page 193
 Application Installation
0..*

: DomainManager : ApplicationFactory Domain Profile ODM Event

Channel : Log

: Client

1. installApplication()
An application installation request is sent
to the DomainManager.

1.1. add Profile

Add the application's S/W Profile into the
Domain Profile.
1.2. <<create>>
Construct an ApplicationFactory for the
specified application software profile.

The DomainManager sends an event

to the ODM Event Channel to
1.3. push()
indicate the installation of the
application.

Log the result of application installation. 1.4. writeRecords()

Page 194
 Listing Installed Applications
For a user to start an application, : DomainManager
they must be aware of the types of
applications available in the system
and then be able to command the : Client
creation of a new instance of a
selected application type.
1: applicationFactories()
A request for getting a list of installed
applications is sent to DomainManager.

2: List of installed Applications (created ApplicationFactories)

The desired ApplicationFactory is

chosen.

Page 195
 Application Creation
1..* 1..* 0..* 0..* 0..* 0..*
appResFac :
: ResourceFactory : Port ODM Event
: Client : ApplicationFactory : LoadableDevice : ExecutableDevice : Resource : Log Channel

1. create()
An application creation request is
sent to ApplicationFactory. After
evaluating the application's The ApplicationFactory
SW profile, the ApplicationFactory
retrieves object references of
Allocates any required capacities 1.1. allocateCapacity()
on all applicable devices.
all Resource Factories from
1.2. allocateCapacity()
the Naming Service.
1.3. load()
Loads all required SW on all
1.4. load()
applicable devices. The ApplicationFactory
retrieves object references of
Creates all Resource Factories
and Resources on all applicable
1.5. execute() 1.5.1. <<create>> all Resources it directly
devices.
1.6. execute() creates from the Naming
1.6.1. <<create>>
Service. Object references of
1.7. createResource()
ResourceFactory-created
Commands all Resource Factories
to create their corresponding
1.7.1. <<create>> Resources are returned by the
resources.
ResourceFactory
1.8. initialize()
Initializes all app’s resources.
createResource operation.
Establishes all port connections 1.9. getPort()
for all app’s resources as 1.10. connectPort()
defined by the app’s SW profile.

Configures all app’s resources as 1.11. configure()

specified by the app’s SW profile.
1.12. push()
Generates an event to indicate the
application has been created.
1.13. writeRecords()
Logs the app creation result.

Finally, a CF Application is returned, providing proxy

interface to Assembly Controller of created Resources. Page 196
Launching a Single
Application Component

Application
Device

3. spawn(EntryPointTask,
1. load (B.out) executeParams)
7. <<create>> 2. execute(EntryPointTask,
executeParams)
6. initialize()/getPort()/ Component
Return Created Application B
Application Factory connectPort()/configure()

5. resolve() 4. bind()

create(initConfiguration, Naming
deviceAssignments) Service
Domain
Profile

Page 197
Use of Configuration and Execute
Parameters during Application Component
creation

Configuration and Execute properties and their default

values are defined in a Properties Descriptor, located in
a Property File of the Application’s Software Assembly
Descriptor (SAD) in the Domain Profile.
CF will modify those properties based on the following
precedence order:
– ApplicationFactory create method (platform specific overrides)
– SAD file (application specific overrides)
– SPD file (different implementation overrides)
– SPD Property file
– SCD Property file

Page 198
Connecting Application
Components
Uses the service Provides a service

Application 4. requestService() Application

Component A Component B
<<create>>
2. getPort() <<create>>
1. getPort()
3. connectPort()
Application
Factory
Return Created
Application

create(initConfiguration,
deviceAssignments)
Domain
Profile

Page 199
 Listing Running Applications
: DomainManager

: Client

1: applications()
A request for list of running applications is
sent to the DomainManager.

2: List of running applications

(CF::Applications instantiated by installed ApplicationFactories)

Page 200
 Invoking Operations on a
Single Application Component
: Application Assembly Controller : Component B
Resource

1) initialize() is implemented as a null operation at the

: Client
Application object and not forwarded to an Assembly
Controller.
2) releaseObject() means application tear down and is
1: configure(), query(), start(), stop(), runTest() directed to each component in the application.
3) getPort() returns an application port that was identified
by the application’s SAD file as being “external”.
2: configure(), query(), start(), stop(), runTest()

3: configure(), query(), start(), stop(), runTest()

Page 201
 Application Teardown

1: releaseObject() 13: push ODM Event

Channel

: Client : Application
12: writeRecords()
: Log

11: unbind()
: Port 2: disconnectPort()

Naming
3: releaseResouce() Service
4: shutdown() 5: releaseObject() 6: terminate() 7: unload()
8: unload() 10: deallocateCapacity()
9: deallocateCapacity()
: ResourceFactory
: Resource : LoadableDevice
: ExecutableDevice

Page 202
SCA IDL Modules
 SCA IDL Modules
Replaced with OMG Light Weight
Log Service in SCA V2.2.1

OMG Naming
OMG Event
Service
Service

Page 204
 CF IDL Module
CF

PortSupplier FileManager

FileSystem
Port

File
LifeCycle

Application

PropertySet
Application
Factory

TestableObject Domain
Resource Resource Device Loadable Executable Aggregate Device Manager
Device Manager
Factory Device Device

Page 205
Log Service The Log interface, types for a log
producer to generate standard SCA log

IDL Module records, and types necessary to control

the logging output of a log producer.

ice
e rv
gS
LogService t W
h .2.1 e
eig h t L o
< < C O R B A E num > >

g
L o g L e ve lT y p e

L i
<<CORBATypedef>>
2 l
F A IL U R E _ A L A R M

u
D E G R A D E D _A LR A M

G A V
LogLevelSequenceType
o d
E
F
X C E P T IO N _ E R R O R
LO W _C O N TR O L_E R R O R

O M S C gM
R
U
A N G E _E R R O R

e
S A G E _E R R O R

ith o
n L ruct> >tu
i<<CORBASt s f
A

a
S
cD M IN IS T R A T IV E _ E V E N T
T A T IS T IC _ R E P O R T

r
P R O G R A M M E R _D E B U G 1

d w L w Sta nte ce P
P
R O G R A M M E R _D E B U G 2
R O G R A M M E R _D E B U G 3

a ce os g
ProducerLogRecordType
o r I r
P
P
f a ce
R O G R A M M E R _D E B U G 4
R O G R A M M E R _D E B U G 5

p l C
producerId L
: string e
m In te te P

fa
R O G R A M M E R _D E B U G 6

r
Re
P R O G R A M M E R _D E B U G 7

u
P R O G R A M M E R _D E B U G 8

producerName : string
n s e r I
P

n
R O G R A M M E R _D E B U G 9

c
P R O G R A M M E R _D E B U G 10

logData : string
C o u t or P R O G R A M M E R _D E B U G 11

d
P R O G R A M M E R _D E B U G 12

o g ro tra
level : LogLevelType
P R O G R A M M E R _D E B U G 13

L gP
P R O G R A M M E R _D E B U G 14

n is P
P
R O G R A M M E R _D E B U G 15
R O G R A M M E R _D E B U G 16

Lo dmi
g A
Lo Log Page 206
StandardEvent Types necessary for an event

IDL Module producer to generate standard

SCA events.

StandardEvent
<<CORBAEnum>>
St ateChangeCat egoryTy pe <<CORBAStruct>>
ADMINISTRATIVE_STATE_EVENT StateChangeEventType
OPERATIONAL_STATE_EVENT producerId : st ring
USAGE_STATE_EVENT sourceId : string

<<CORBAEnum>>
<<CORBASt ruct >> SourceCat egoryType
<<CORBAEnum>> DomainManagementObjectAddedEventType DEVICE_MANAGER
StateChangeType producerId : string DEVICE
LOCKED sourceId : string APPLICATION_FACTORY
UNLOCKED sourceName : string APPLICATION
SHUTTING_DOWN sourceIOR : Object SERVICE
ENABLED
DISABLED
<<CORBAStruct>>
IDLE
DomainManagement Object RemovedEventType
ACTIVE
BUSY producerId : string
sourceId : string
sourceName : string

Page 207
PortTypes
IDL Module Sequences of base CORBA types
for optional Port operations

PortTypes
<<CORBATypedef>> <<CORBATypedef>> <<CORBATypedef>>
CharSequence WcharS equence WstringSequence

<<CORBATypedef>> <<CORBATypedef>> <<CORBATypedef>>

ShortSequence UshortS equence FloatSequence

<<CORBATypedef>> <<CORBATypedef>> <<CORBATypedef>>

LongSequence LongLongSequence UlongSequence

<<CORBATypedef>> <<CORBATypedef>> <<CORBA Typedef>>

DoubleSequence LongDoubleSequence UlongLongSequence

<<CORBATypedef>>
BooleanSequence

Page 208
References
References
http://jtrs.army.mil/
– Joint Tactical Radio System Program Background
– Software Communications Architecture Overview, Goals, and
Standardization
– Software Communication Architecture Specification, V2.2
– Software Communications Architecture Support and Rationale
Document, V2.2
– Software Communications Architecture Developers Guide, V1.1
– Software Communications Architecture Application Program Interface
Supplement, V1.1
– Software Communications Architecture Security Supplement, V1.1
– Software Communications Architecture Training Course
http://www.omg.org
– PIM and PSM for Software Radio Joint Revised Submission
– Experience Report from Developing and Fielding the First SCA 2.0 JTRS
Radio, BAE Systems, OMG Real-Time & Embedded Workshop July 2003
http://www.sdrforum.org
– Software Defined Radio Definition
Page 210