SCA Platform Abstraction

The Software Communications Architecture (SCA) promotes reuse of software components by providing techniques and methods to abstract platforms from software applications.

Benefits of Platform Abstraction:

• Clear separation of the application’s core business logic from the underlying hardware and software in which it is to execute.
• Higher value business logic implementations, as SCA source code is easier to port from one platform to another.
• Application developers can focus on the actual application rather than spending time integrating it with the platform.
• Change of hardware or software is simpler as they are not tightly integrated and thus easier to upgrade.

SCA Platform abstraction is achieved through the identification of an Operating Environment (OE) that defines the Real-Time Operating System, inter process communication mechanism, and physical hardware in which the application is to be executed.

SCA Elements

• SCA Core Framework: Run-time Deployment Engine of SCA Software Components.
• SCA Devices: Software proxies that enables communication from/to an SCA Application to/from physical hardware.
• SCA Applications: Assembly of highly reusable and portable SCA components that 1) are deployed and executed by the SCA Core Framework, and 2) that interacts with the physical hardware via SCA Devices.
• CORBA Middleware: Inter Process Communication (IPC) mechanism that provides location transparency as well as programming language and operating system independence for SCA components.
• POSIX AEP: Application Environment Profile (AEP), subset of the POSIX specification, that identifies the operations that can be invoked from an SCA Application into the underlying Operating System (OS).
• Operating System: Real Time Operating System (RTOS) provided by the SCA System that implements the operations defined in the SCA Application Environment Profile (AEP- POSIX APIs).
• Digital Hardware: Combination of Processing Elements (E.g. GPP, DSP, GPU, FPGA) that are used by the SCA system to deploy and execute SCA Applications
• RF Hardware: Physical Hardware that provides access to the SCA System to transmit and receive waveforms to/from the radio frequency spectrum.

• Hardware Abstraction

  The hardware platform is abstracted through a set of common application programming interfaces (APIs) that define the functionalities of the hardware, independently of their implementation.

  The application software is shielded from hardware changes by making invocations to well-defined APIs for different types of hardware. To do this, SCA platforms provide software proxies called SCA Devices that interact with the software application using such well-defined APIs, and that forward the application’s invocations to the physical hardware using the latter’s native drivers. Changing the hardware therefore does not require any modification of the application software, it only requires an adaptation of the software proxy to use the new hardware via its own native drivers.

  

  SCA Devices can be used as proxies to any kind of hardware for software development in embedded systems domains.

• Operating System Abstraction

  

  Embedded systems software is often developed targeting only one Real-Time Operating System (RTOS) for execution. Such approach causes the software under development to hard-code its interactions with the RTOS, making it difficult to port to a different RTOS. Business opportunities are often cut short because of the lack of capacity to take fully functioning source code from one RTOS to another. The SCA addresses this constraint with the definition of an Application Environment Profile (AEP) that identifies a set of operations that can be invoked into a compliant RTOS from an SCA Application. The SCA AEP is a subset of the Portable Operating System Interface (POSIX) standard, and most RTOS nowadays comply with the POSIX SCA requirements. The impact on embedded systems software development under this approach is profound, as now complex algorithms implemented in source code can be easily moved from one RTOS to another.

• Inter Process Communication

  Current technology allows for parallel processing across distributed systems. SCA addresses distribution by using the Common Object Request Broker Architecture (CORBA) as a standardized middleware to enable inter-process communications between software components. By using pluggable transports, CORBA implementations nowadays provide as fast and efficient communications as any proprietary mechanism used to transfer messages from one software object to another. The SCA benefits from CORBA as it delivers software that is more portable due to CORBA’s location transparency and operating system and programming language independence.