Software Communications Architecture and Related Specifications Overview

1
Software Communications Architecture and Related
Specifications Overview

• Kevin Richardson
• 09 April 2006

2
What is An Architecture?It is an Enabler

• 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)

3
What is the SCA?

• The JTRS SCA specifies an open, non-proprietary
  architectural framework

• 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

Domain Mgr
POSIX CORBA
FPGA
GPP
Devices
4
How can the SCA Benefit DoD?
same waveform software runs on different
hardware sets
Recompilation
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
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
SCA Core Framework Definition

• 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

9
Platform Mangement
10
Domain Mgr Knows Devices,Applications,
Resources
HMI access uses Dom Mgr
HMI
SAD describes the components that comprise an
application
DCD defines characteristics of devices to be
loaded
DomainManager
One Dev Mgr per CORBA-capable processor
An App Fac is created for each installapplication,
i. e. SAD
SAD
ApplicationFactory
DeviceManager
DCD
Resources
Devices
Application
On starting Application
HardwareDevices

• XML Profiles provide application Metadata
• resource Software Profile Descriptor a
  component
• install creates an Application Factory
• An Application Factory starts up an Application
  instance

11
Resource

• 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
State
LoadExecute

• A Device IS a resource that provides a HW
  abstraction
• State reflects state of the hardware Usage,
  Admin, Operational

13
Core Framework IDL Relationships
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
  platforms 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
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, contd
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, contd
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.

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
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 channels distributed
  devices
• Radio Services within the Radio Set

29
UML Profile for SWRadio Infrastructure, contd
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,
contd
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, contd

• 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, contd

• 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