"SCA 2.2.2标准规范及附件详解"

2.2.2

需积分: 10 77 浏览量更新于2024-04-17 收藏 3MB PDF 举报

The SCA_VERSION_2_2_2.PDF document contains the SOFTWARE COMMUNICATIONS ARCHITECTURE SPECIFICATION, which was finalized on 15 May 2006, as Version 2.2.2. This specification includes various attachments such as Domain Profile Document Type Definitions and Common Properties Definitions, as well as appendices for the Core Framework IDL, Domain Profile, Glossary, and SCA Application Environment Profile. The document also features SOFTWARE COMMUNICATIONS ARCHITECTURE EXTENSIONS. Prepared by the JTRS Standards Joint Program Executive Office (JPEO) Joint Tactical Radio System (JTRS) Space and Naval Warfare Systems Center in San Diego, the SCA Version 2.2.2 is classified as UNCLASSIFIED and is approved for public release with unlimited distribution. This version includes revisions for formal release and serves as a comprehensive guide for implementing the Software Communications Architecture in various communication systems.

SCA version 2.2.2 FINAL / 15 May 2006

2-1

2 OVERVIEW

This section presents an architectural overview of the SCA which defines the fundamental

organization of the components that compose this specification. A high-level description of the

components, their responsibilities, as well as their relationship to each other and the environment

are also provided. Technical details and specific requirements of the architecture and individual

components are contained in section 3.

2.1 ARCHITECTURE DEFINITION METHODOLOGY

The architecture has been developed using an object-oriented approach including current best

practices from software component models and software design patterns. Unless stated, no

explicit grouping or separation of interfaces is required within an implementation. The interface

definitions and required behaviors that follow in section 3, define the responsibilities, roles, and

relationships of components implementing that interface. Within this specification, the Unified

Modeling Language (UML) [2] is used to graphically represent interfaces and the Interface

Definition Language (IDL) provided in Appendix C contains the textual representation of the

interfaces.

2.2 ARCHITECTURE OVERVIEW

2.2.1 Goals and Context

The goal of this specification is to provide for the deployment, management, interconnection,

and intercommunication of software components in embedded, distributed-computing

communication systems. This specification is targeted towards facilitating the development of

software defined radios (SDRs) with the additional goals of maximizing software application

portability, reusability, and scalability through the use of commercial protocols and products.

Although there are many definitions of a SDR, it is in essence a radio or communication system

whose output signal is determined by software. In this sense, the output is entirely

reconfigurable at any given time, within the limits of the radio or system hardware capabilities

(e.g. processing elements, power amplifiers, antennas, etc.) merely by loading new software as

required by the user. Since this software determines the output signal of the system, it is

typically referred to as “waveform software” or simply as the “waveform” itself. This ability to

add, remove, or modify the output of the system through reconfigurable and redeployable

software, leads to communication systems capable of multiple mode operation (including

variable signal formatting, data rates, and bandwidths) within a single hardware configuration.

Simultaneous multi-mode operation is possible when a multi-channel configuration is available.

Since the functionality of software itself is virtually limitless, there is a large degree of

dependency placed on the ability to select and configure the appropriate hardware to support the

software available or required for a specific system. The selection of hardware is not restricted to

the input/output (I/O) devices typically associated with communication systems (analog-to-

digital converters, power amplifiers, etc.). It is also dependent on the type and capabilities of the

processing elements (General Purpose Processors (GPP), Digital Signal Processors (DSP), Field-

Programmable Gate Arrays (FPGA), etc.) that are required to be present, since typically the

software required to generate a given output signal will consist of many components of different

SCA version 2.2.2 FINAL / 15 May 2006

2-2

types based on performance requirements. From an illustrative view, this results in a system that

is represented by a variable collection of hardware elements which need to be connected together

to form communication pathways based on the specific software loaded onto the system. The

role of the SCA is then to provide a common infrastructure for managing the software and

hardware elements present in a system and ensuring that their requirements and capabilities are

commensurate. The SCA accomplishes this function by defining a set of interfaces that isolate

the system applications from the underlying hardware. This set of interfaces is referred to as the

Core Framework of the SCA.

Additionally, the SCA provides the infrastructure and support elements needed to ensure that

once software components are deployed on a system, they are able to execute and communicate

with the other hardware and software elements present in the system.

2.2.2 Core Framework

The Core Framework is the essential set of open application-layer CORBA interfaces and

services which provide an abstraction of the underlying system software and hardware. The

Core Framework consists of:

Base Application Interfaces: Port, LifeCycle, TestableObject, PropertySet,

PortSupplier, ResourceFactory, and Resource), which provide the management and

control interfaces for all system software components.

Base Device Interfaces: Device, LoadableDevice, ExecutableDevice, and

AggregateDevice, which allows the management and control of hardware devices within

the system through their software interface,

Framework Control Interfaces: Application, ApplicationFactory, DomainManager,

and DeviceManager, which control the instantiation, management, and

destruction/removal of software from the system,

Framework Services Interfaces: File, FileSystem, and FileManager, that provide

additional support functions and services.

2.2.3 Definitions

The SCA differentiates between waveform “application” software – software that manipulates

input data and determines the output of the system – from the software that provides the

capabilities for waveforms to execute and access to the systems hardware resources. The

“application” software implements the Base Application Interfaces identified in section 2.2.2.

The software components that provide access to the system hardware resources are referred to as

SCA “devices” that implement the Base Device Interfaces. Non-hardware (software-only)

resources provided by the system for use by applications are generically referred to as “services”,

however the SCA does not specify an interface that must be realized by these components. The

SCA standardizes the component interfaces but does not place implementation requirements (e.g.

transport mechanisms) on the software.

The software components which provide for the management and execution of the SCA

applications and devices comprise the SCA-defined operating environment (OE). The OE

consists of an operating system (OS), CORBA middleware (including the OMG-defined Event

SCA version 2.2.2 FINAL / 15 May 2006

2-3

and Naming Services), and the elements defined by the Framework Control and Service

Interfaces.

2.2.4 Structure

The architectural structure of the SCA is presented in Figure 2-1. In the SCA, an application

consists of multiple software components that are loaded onto a distributed-processing system.

These components are managed by an implementation of the Framework Control Interfaces. The

application components communicate either with each other or with the services and devices

provided by the system through extensions of the SCA-defined Port interface. Similarly,

communications between the application and the Framework Services Interfaces are

accomplished through the CORBA middleware. It is intended that the APIs to the services and

devices (“System Components” in Figure 2-1) be standardized for a given system or domain so

that in conjunction with the Framework Interfaces, all communications between the application

and the system are uniform across multiple systems. However, being system and domain

specific, the standardization of these interfaces is outside the scope of this specification.

An application may access OS functionality but is restricted to the operations enumerated in the

SCA Application Environment Profile (Appendix B) which is a subset of the Portable Operating

System Interface (POSIX) specification [4]. POSIX is an accepted industry standard and its real-

time extensions are compatible with the requirements to support the OMG CORBA

specification. Since defined POSIX profiles can encompass more features than are necessary to

control a typical implementation, this specification defines a minimal POSIX profile to facilitate

attainment of the SCA objectives.

Similar to the application components, system components are managed by the Framework

Control Interfaces through the Base Device Interfaces and are limited . However, unlike

application components, system components are not restricted in their use of functionality

provided by the OS since these components are in general, system specific.

剩余125页未读，继续阅读

七升

粉丝: 0
资源: 1

"SCA 2.2.2标准规范及附件详解"

SCA标准2.2

SCA中文规范和其他资料

SCA_specification_version_2_2_2

sca_powerallocation.m sca算法matlab代码

epsilon_sca_r

你从U盘拷贝了一个可执行程序sca_test到专用文件工作站上，sca_test程序运行在d5000用户（用户组d5000），在你拷贝源码到应用服务器之前，你需要先执行什么命令

Fortify_SCA_24.2

最新资源