Upload
daniel-welch
View
219
Download
1
Tags:
Embed Size (px)
Citation preview
1
Software Communications Architecture and Related Specifications Overview
Kevin Richardson
09 April 2006
2
• Definition of Software Architecture:A software architecture is characterized by a particular combination of software
components and connections.
The SCA provides a framework, not functionality.
• The JTRS Software Communications Architecture(SCA) Enables:– porting of “waveforms”
– reuse of software (largely internal to development organization)
– extensibility of hardware and software (emphasis on modeling)
– interoperability between platforms
– use of commercial product lines (as it gains commercial acceptance)
What is An Architecture?It is an Enabler
3
– Independent ofwaveform functionality
– “Component oriented” – profiles describe HW / SW components
– Defines SW Interfaces for data connection and management control
– Defines a common management framework
• to configure, connect and tear-down distributed applications
What is the SCA?What is the SCA?
• The JTRS SCA specifies an open, non-proprietary architectural framework
GPP
GPP GPP
DSP DSPFPGA
Devices
POSIX CORBA
RF
D
o
m
a
i
n
M
g
r
4
How can the SCA Benefit DoD?
ADCRF
Analog
ToApplications
Recompilation
Recom
pila
tion
GPP
GPP
DSPFPGA
Devices
POSIX CORBA
R
FDomain
M
g
rGPP
GPP GPP
DSP DSPFPGA
Devices
POSIX CORBA
R
FD
o
m
a
i
n
M
g
r
“same” waveform software runs on different hardware sets
5
Criteria for the SCA
– Based on Open, Commercial Standards• OMG, IEEE, IETF
– Supports a Family of Radios • Interoperable,
• Programmable
• Scaleable (handheld to fixed-station),
– Maximizes Platform Independence of Software from Hardware• Application and Device Portability & Reuse
• Rapid Technology Insertion Over Time
– Extendible to New Waveforms and/or Hardware Components
6
Core Framework (CF)
Commercial Off-the-Shelf (COTS)
Applications
OperatingEnvironment (OE)
Red Hardware Bus
CFServices &
Applications
CORBA ORB &Services
(Middleware)
Network Stacks & Serial Interface Services
Board Support Package (Bus Layer)
Black Hardware Bus
CFServices &
Applications
CORBA ORB &Services
(Middleware)
Network Stacks & Serial Interface Services
Board Support Package (Bus Layer)
Operating System
Core Framework IDL
Non-CORBAModem
Components
Non-CORBASecurity
Components
Non-CORBA I/O
Components
RF
ModemComponents
Link, NetworkComponents
SecurityComponents
ModemAdapter
SecurityAdapter
SecurityAdapter
I/OAdapter
I/OComponents
MAC API LLC/Network API LLC/Network API
Link, NetworkComponents
Security API
Operating System
Physical API
I/O API
(“Logical Software Bus” via CORBA)
SCA Software Structure
7
The SCA “Model”
• Software
– Operating Environment
• POSIX-based operating system (OS)
• CORBA / Interface Definition Language (IDL)
• JTRS Core Framework (CF)
• Domain Profile (XML-based)
• Hardware
– Classes (Operations and Interfaces)
• Rules for Implementation
– How the Architecture is applied to products
• The SCA does not …– specify implementation-level details– define all the elements or interfaces for a SDR– guarantee portability
8
• The SCA CF is a “core” set of interfaces that provide an abstraction of the
underlying software and hardware layers for software application designers
• CF Interfaces (defined in IDL) consist of:
- Base Application Interfaces (Port, LifeCycle, TestableObject, PortSupplier, PropertySet,
ResourceFactory, and Resource) that can be used by all software applications
- Framework Control Interfaces (Application, ApplicationFactory, DomainManager, Device,
LoadableDevice, ExecutableDevice, AggregateDevice, and DeviceManager) that provide control of
the system
- Framework Service Interfaces (File, FileSystem, and FileManager) that provide interfaces for
distributed file access services to software application components
- Domain Profile that describes the properties of hardware devices and software components in the
system and enables application deployment
SCA Core Framework DefinitionSCA Core Framework Definition
9
CORBA
CORBA-capable processor
Domain Manager
Device Manager
Each Device Manager responsible for booting its Devices and Services
HardwareDevices
HardwareDevices
HardwareDevices
DCD
All Dev Mgrs report toDom Mgr
DCD tells Dev Mgr what HW devices exist
1 Domain Mgr1 Device Mgr per CORBA-capable processor
• 1 Domain Mgr per JTR Set• 1 Device Mgr per CORBA Capable processor
• Device Mgr starts up its device (in parallel)• Primarily works at “power on”
Power activates: OS ORB Device Managers 1 Domain Manager
Platform MangementPlatform Mangement
10
Domain Mgr Knows Devices,Applications, & Resources
• XML Profiles provide application Metadata• “resource” + Software Profile Descriptor = a “component”• “install” creates an Application Factory• An Application Factory starts up an Application instance
DomainManager
ApplicationFactory
DeviceManager
HMI
Res
ourc
es
Dev
ices
SADDCD
HardwareDevices
One Dev Mgr per CORBA-capable processor
HMI access uses Dom Mgr
An App Fac is created for each installapplication, i. e. SAD
SAD describes the components that comprise an application
DCD defines characteristics of devices to be loaded
ApplicationOn starting Application
11
Resource
Collectionof
FunctionalityProgrammer-Defined
StartStop
ControlData
User-DefinedInterfaces
Get Port
Run TestInitializeRelease
• A resource “packages” together object code that runs within a processor • Provides set of “control” operations (primarily used by Core Framework)• Functionality and Interfaces (ports) are supplied by programmer
12
Device
Collectionof
FunctionalityProgrammer-Defined
StartStop
ControlData
User-DefinedInterfaces
Get Port
Run TestInitializeRelease
State
LoadExecute
Aggregate
Hardware
• A Device IS a resource that provides a HW abstraction• State reflects state of the hardware: Usage, Admin, Operational
13
Core Framework IDL RelationshipsCore Framework IDL Relationships
<<Interface>>
Device <<Interface>>
Application
<<Interface>>
DomainManager
inheritsfrom
uses
<<Interface>>
ApplicationFactory
<<Interface>>
DeviceManager
<<Interface>>
FileManager
deviceManagers
1..*
0..*
applicationFactories
fileMgr1
applications
0..*
uses
<<Interface>>
File
fileSys
0..1
<<Interface>>
Resource<<Interface>>
ResourceFactory
Core Framework Interface
Implemented byNon-Core Applications
Core Framework Interface
Implemented asCore Application Services
Legend
<<Interface>>FileSystem
<<Interface>>
LoadableDevice
<<Interface>>
ExecuteableDevice
<<Interface>>
AggregateDevice 0..*devices
<<Interface>>
PropertySet
<<Interface>>
PropertySet<<Interface>>
LifeCycle<<Interface>>
TestableObject<<Interface>>
PortSupplier<<Interface>>
Port
Base Application Interfaces
Framework Control Interfaces
Framework Services Interfaces
14
SCA Base Application Interfaces
• Port– used to connect Resource Components
• LifeCycle– used to initialize or release Resources
• TestableObject– used to test a Resource
• Port Supplier– used to obtain a specific port
• PropertySet– provides operations to access Resource properties
• ResourceFactory– Used to create / tear down Resources
• Resource– provides common interface for Resource control and configuration
15
SCA Framework Control Interfaces
• Application– CF provided container for Resources that make up application
• provides interfaces for control, configuration, status and tear-down
• ApplicationFactory– used to create application (waveform) instances
– based on Domain Profile• allocates SW (Resources) to HW (Devices) - allocates capacities
• connects Resources that make up application
• performs initial configuration
• DomainManager– Provides interface for DeviceManager, Device and Application registration
– Provides access to registered DeviceManagers, installed and Running applications, the platform’s FileManager
– Provides interface to HCI to access the domain and its capabilities (Devices and Applications)
16
SCA Framework Control Interfaces (cont.)
• Device
– A software proxy for a physical hardware device
– Represents CF interface between applications and devices
– Typically one Device per HW device
– Loadable, Executable, and Aggregate Devices extend behavior of the
Device Class
• DeviceManager
– Manages a set of logical Devices and services
17
SCA Framework Services Interfaces
• File
– Provides access to files within the radio
– Allows access across processor boundaries (distributed file systems)
• FileSystem
– Enable remote access to physical file systems
– Allows creation, deletion, copying, etc of files
• FileManager
– Manages multiple distributed FileSystems
– Looks like a FileSystem to client
18
SCA Domain Profile
• A set of files that describe HW and SW components making up
an SCA system domain
• eXtensible Markup Language (XML) format
• Document Type Definitions (DTDs) describe the files
[Customized to better address Software Radio Needs]
19
SCA Status
• SCA is being accepted by Industry– An “SCA equivalent” exists within the family of OMG Standards
– Commercial tool vendors and industry have provided some SCA tools• PrismTech, Zeligsoft and CRC
• The SCA has undergone three phases of architectural validation and provides the backbone for JTRS Cluster 1
• The SCA and its underlying technologies target a GPP based platform however many of the abstractions are applicable to other processing environments
• The JTRS program office has a plan in place to continue to evolve the SCA
20
Software Communications Architecture
Note: All dates represent estimated OMG schedules
Finalization
April 05
Schedule for standardization of SCA related specifications at theObject Management Group (OMG)
Nov 04Jul 04
Formal spec
Adopted spec
Finalized spec
Sep 05
Formal
Standard
July 03
Lightweight Log ServicesSpecification Adoption
Nov 03
Lightweight Services
Feb 04
PIM and PSM for SW Radio
June 04
Lightweight CCM
Nov 03
Deployment & Configuration
21
SWRadio MDA Principles
• UML Profile for SWRadio extends UML for SWRadio tool support: validation, system engineering, and SWRadio component development
• PIM has been primarily structured as a set of facilities each addressing a key aspect of SWRadio
• Well-defined set of modeling conventions– Naming conventions
– Modeling conventions
– Subset of UML notation
– Specific semantics of this notation in the context of this PIM
• Conforms to MDA– PIM can be transformed to different component platforms
• CORBA-PSM, Java-PSM, etc.
• Compatible with existing OMG standards– MOF
– UML
22
SWRadio MDA Principles, cont’d
OMG UML
Meta ObjectFacility (MOF)
Meta-Model Layer (M2)
Meta-Meta-Model Layer (M3)
PIM & PSM Layer (M1)
Domain & PlatformTechnologyprofiles
«extends»
«instanceOf»
Waveform, Device,Radio Infrastructure &Service PSM Components & Artifacts (XML Descriptors, Executables)
«refine»
Runtime or Deployed Artifacts Layer (M0)
Waveform, Device, Radio Infrastructure& Service ComponentsPIMs
UML Profiles forSWRadio,CORBA, Java, C++, XML Schema
«instanceOf» «instanceOf»
Waveform, Device, Radio Infrastructure& Service ComponentsPSMs, CF Interfaces, XML Descriptors
«instanceOf»
Profiles M1 Data
23
SWRadio Development Viewpoints
• To address the issues of the different actors involved in SWRadio product developments, the current profile was developed with three main viewpoints in mind: – the viewpoint of application and device developers,
– the viewpoint of infrastructure/middleware providers, and
– the viewpoint of SWRadio platforms providers.
• These three viewpoints define distinct sets of concepts (and stereotypes) that are required in different contexts.
24
SWRadio Development Viewpoints, cont’d
Radio Control Facilities
(from Facilities PIM)
Infrastructure Providers
Application and Device Providers
Common Radio Facilities
(from Facilities PIM)
ApplicationApplicationResourceComponent
*1..*
+componentAssembly
*
+appComponent
1..*
DeviceComponent
**
**
DeviceDriver
1..*
*
+logicalDevice1..*
+deviceDriver *
RadioSystem
LogicalCommunicationChannel
1..*1..*
CommEquipment
1..*
1
+deviceDriver
1..*
+commEquipment
1
RadioSet
1
1..*
1
1..*
1..*1..*
Data Link Layer Facilities
(from Facilities PIM)
Common Layer Facilities
(from Facilities PIM)
Physical Layer Facilities
(from Facilities PIM)
Application Deployment
(from SWRadio Deployment)
Radio Services Element Definitions
Radio Management
SWRadio Platform Providers
PIM Facility
25
UML Profile for SWRadio
• To be consistent with the three development viewpoints, the UML Profile for SWRadio is partitioned in three main packages:
– the Applications and Devices Components, – the Infrastructure, and – the Communication Equipment package.
• Each package defines the set of concepts and UML stereotypes required to perform a specific role in the development of an SWRadio product.
Application and Device Components
Communication Equipment
Infrastructure
26
UML Profile for SWRadio Application & Device Components
• Application Components– Contains the component stereotypes for application developers– Application, ApplicationResourceComponent, LayerResource (Data Link, MAC,
Physical)
• Base Types– Contains the common types for defining SWRadio components.
• Interface & Port Types– Contains the port and interface stereotypes for SWRadio interfaces and components
• Device Components– Contains the component stereotypes for device developers– Logical Device, Loadable and Executable
• Properties– Contains property stereotypes for SWRadio components– Configure, Query, Characteristic, Capacity
• Resource Components– Contains the interface and component stereotypes for waveform and device
developers– ControllableComponent, LifeCycle, PropertySet, ResourceComponent, etc.
27
UML Profile for SWRadio Resource Components
LifeCycle<<interface>>
PropertySet<<interface>>
TestableObject<<interface>>PortSupplier
<<interface>>
ControllableComponent<<interface>>
SWRadioComponent<<stereotype>>
PortConnector<<interface>>
ResourceComponent<<stereotype>>
SWRAPI<<stereotype>>
*
*
*
*<<swapiRealization>>
*
*
*
*
<<swapiUsage>>
ComponentIdentifier<<interface>>
Resource<<stereotype>>
ResourceFactory<<stereotype>>
*
0..1
+product*
+creator
0..1
28
UML Profile for SWRadio Infrastructure
• Radio Services– Common services within the radio platform that are utilized by
applications
– Managed component service
• Radio Management– RadioSet, RadioSystem, and Device Management
• Communication Channel– Physical, IO, Security, and Processing Channel
– Captures the relationships between channels and SWRadio devices
• Application Deployment– Components and Artifacts stereotypes for the deployment of:
• Waveforms on communication channel’s distributed devices
• Radio Services within the Radio Set
29
UML Profile for SWRadio Infrastructure, cont’d
RadioSystem(from Communication Channel)
RadioSet(from Communication Channel)
RadioSystemManager<<stereotype>>
11
+radioSystem
1
+radioSystemManager
1
LogicalCommunicationChannel(from Communication Channel)
<<stereotype>>
RadioManager<<stereotype>>
11
+radioSet
1
+radioManager
1
0..1
1..*
+radioSystemManager
0..1
+radioManager1..*
ApplicationFactory(from Application Deployment)
<<stereotype>>ApplicationManager(from Application Deployment)
<<stereotype>>
CommChannel<<stereotype>>
1 1
+commChannel
1
+logicalCommChannel
1
1..*1..*
*
1..*
+waveformDeployer
*
1..*0..1
1+deployedWaveform
0..1
1
DomainManager<<stereotype>>
Service<<stereotype>>
DeviceManager<<stereotype>>
1..*
1
+deviceManagrRegistrant 1..*
+domainRegistrar
1
+registeredService
1..*1..*
30
UML Profile for SWRadio Communication Equipment
• Stereotypes for SWRadio devices
• Communication Equipment describes the relationships and attributes that are appropriate for radio devices.– Crypto Device - performs encryption and decryption on asset of data.
– I/O Device - describes the relationships and attributes that are appropriate for I/O devices
• Antenna, Amplifier, Filter, Frequency Converter, audio, serial, etc.
– Power Supply - provides electrical power to other devices.
– Processor Device - processes digital or analog data.
• Port Types– Analog & Digital
• Property Types– Characteristic & Configure
31
UML Profile for SWRadio Communication Equipment, cont’d
IODevice<<stereotype>>
PowerSupply<<stereotype>>
Processor<<stereotype>>
CryptoDevice<<stereotype>>
RequiredTypes<<modelLibrary>>
+ AmplitudePhaseResponse+ AntennaCalibration
+ AntennaType...
AnalogInputPort<<stereotype>>
AnalogOutputPort<<stereotype>>
DigitalPort<<stereotype>>
CommEquipment
<<characteristicproperty>> equipmentSize : Size<<characteristicproperty>> equipmentWeight : Weight<<characteristicproperty>> maintenancePeriod : Time [0..1]<<characteristicproperty>> maxOperatingTemperature : Temperature<<characteristicproperty>> meanTimeBetweenFailures : Time [0..1]<<characteristicproperty>> minOperatingTemperature : Temperature<<characteristicproperty>> powerConsumption : Power<<characteristicproperty>> radiationCapability : Radiation [0..1]<<configureproperty>> lastMaintenanceCheck : Date [0..1]<<queryproperty>> equipmentInformation : PlugAndPlayInformation<<queryproperty>> temperatureStatus : Temperature [0..1]
<<stereotype>>
1
*
+device
1 +analogReceiverPort
*
1 *
+device
1
+analogTransmitterPort
*
+digitalPort
+device
1
*
1
*
Device(from UML)
<<metaclass>>
<<extension>>
32
SWRadio PIM Facilities
• Common Radio Facilities– Provides common service definitions that are applicable for all
applications (waveforms or radio control)
– File Services, OMG Lightweight Services (log, event, naming, etc.)
• Common Layer Facilities– Provides interfaces that cross cut through facilities that correlate to
layers. These interfaces can be viewed as building blocks for SWRadio components that realize multiple interfaces.
– Protocol Data Unit, Error Control, Flow Control, Measurement, Quality of Service, and Stream Facilities
33
SWRadio PIM Facilities, cont’d
• Data Link Facilities– Link Layer Control (LLC) facilities. LLC layer provides facilities
to upper layers, for management of communication links between two or more radio sets.
– Data Link Layer (Connectionless, ConnectionLess Ack, Connection), and Medium Access Control Facilities
• I/O Facilities– Defines the configuration properties for Audio and Serial Facilities
34
SWRadio PIM Facilities, cont’d
• Physical Layer Facilities– Modem Facilities
• The modem facilities include all digital signal processing elements required to convert bits into symbols and vice versa.
– RF/IF Facilities• The RF/IF Facilities is used to configure and control the basic devices
of the physical channel. The granularity at which these interfaces are implemented is not specified.
• Radio Control Facilities– Provides for interfaces for radio and channel management.
35
SWRadio PSM
• Automatic PSM generation from PIM and profile definitions– Transformation rule set specified in the specification
• Platform Specific Model– CORBA Modules
• CF– StandardEvent, PortTypes
• DfSWRadio– CommonLayer, DataLinkLayer, CommonRadio, PhysicalLayer, RadioControl
• DSFileServices
– XML Schema• Properties• Communication Channel• Physical Layer Properties
– POSIX
• Other PSMs could be defined
36
SWRadio Lessons Learned
• Benefits– Promotes separation of design / development concerns
• Nothing new (good SW Engineering principles)
– MDA approach requires more formal/complete models• Enables artifact generation
• Impediments to adoption– Lack of tools (transformation, generation, UML extension, MOF
infrastructure)
– Programmatic conflicts exist regarding integrating new specs into an existing product family
37
Summary
• The SCA provides a platform and development language independent architectural framework upon which SDR (and other distributed, component based) applications can be built.
• The underlying platform independent SCA model has been emphasized in areas such as the OMG family of specifications
• The SCA “works” however there are areas for evolution– Resource Constrained processing environments
– Extendiblity into other platform specific middlewares and OEs