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 of waveform 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? The JTRS SCA specifies an open, non-proprietary architectural framework GPP DSP FPGA Devices POSIX CORBA RFRF DomainMgrDomainMgr

4 How can the SCA Benefit DoD? ADC RF Analog To Applications Recompilation GPP DSP FPGA Device s POSIX CORBA RFRF DomainMgrDomainMgr GPP DSP FPGA Devices POSIX CORBA RFRF DomainMgrDomainMgr 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 Operating Environment (OE) Red Hardware Bus CF Services & Applications CORBA ORB & Services (Middleware) Network Stacks & Serial Interface Services Board Support Package (Bus Layer) Black Hardware Bus CF Services & Applications CORBA ORB & Services (Middleware) Network Stacks & Serial Interface Services Board Support Package (Bus Layer) Operating System Core Framework IDL Non-CORBA Modem Components Non-CORBA Security Components Non-CORBA I/O Components RF Modem Components Link, Network Components Security Components Modem Adapter Security Adapter Security Adapter I/O Adapter I/O Components MAC APILLC/Network API Link, Network Components 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 Definition

9 CORBACORBA CORBA-capable processor Domain Manager Device Manager Each Device Manager responsible for booting its Devices and Services Hardware Devices DCD All Dev Mgrs report to Dom Mgr DCD tells Dev Mgr what HW devices exist 1 Domain Mgr 1 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 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 Domain Manager Application Factory Device Manager HMI Resources Devices SAD DCD Hardware Devices 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 Application On starting Application

11 Resource Collection of Functionality Programmer-Defined Start Stop Control Data User-Defined Interfaces Get Port Run Test Initialize Release 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 Collection of Functionality Programmer-Defined Start Stop Control Data User-Defined Interfaces Get Port Run Test Initialize Release State Load Execute 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 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 Finalization April 05 Schedule for standardization of SCA related specifications at the Object Management Group (OMG) Nov 04 Jul 04 Formal spec Adopted spec Finalized spec Sep 05 Formal Standard July 03 Lightweight Log Services Specification 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, contd OMG UML Meta Object Facility (MOF) Meta-Model Layer (M2) Meta-Meta-Model Layer (M3) PIM & PSM Layer (M1) Domain & Platform Technology profiles «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 Components PIMs UML Profiles for SWRadio, CORBA, Java, C++, XML Schema «instanceOf» Waveform, Device, Radio Infrastructure & Service Components PSMs, 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, 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