Component Enabler Best Practices: SCA Component Enabler Best Practices: SCA The place of Zeligsoft...
Embed Size (px)
Transcript of Component Enabler Best Practices: SCA Component Enabler Best Practices: SCA The place of Zeligsoft...
Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler
within the SCA software development process
Mark Hermeling, John Hogg, Francis Bordeleau
This paper illustrates how Zeligsoft Component
Enabler (CE) [ZSFT] can assist in a component-based
software development process for embedded systems.
To do this we will investigate the roles that participate
in a process and document the usage patterns and
benefits of using CE throughout the development process.
This paper focuses on the use of Zeligsoft Component
Enabler version 1.4.
2 INTRODUCTION TO COMPONENT ENABLER
Component-based development refers to both the
development environment and the deployment envi-
ronment of component-based systems. Component-
based systems consist of assemblies of components.
Developers work on components in isolation; they
build them, test them, and deploy them as individual
components. Once deployed, the individual components
are initialized, connected together, and started. The
connected components deliver the full functionality of
the entire system.
The Software Communications Architecture (SCA) [SCA]
is a deployment and configuration architecture for
Software Defined Radio (SDR) managed by the US
Department of Defense Joint Tactical Radio System
(JTRS) [JTRS] Joint Program Office (JPO). It specifies
how to define systems as assemblies of components and
how these assemblies can be deployed to platforms.
CE helps users overcome many of the challenges
associated with building SCA compliant systems [ZSFT-8].
CE enables users to graphically define the system platform
and the (waveform) applications that are deployed to
the system. The visual models give the development
team a clear, common understanding of the hardware
and software architectures, and the component and
device interfaces, including their relationships.
Communication and peer review are the first steps to
building a correct system, but informal descriptions can
still obscure many defects. Since CE graphical models
are semantically rich and precise, CE can automatically
validate them for compliance to the SCA standard. This
ensures that many types of errors cannot occur.
The visual model can also be used to automatically
generate the entire domain profile. The domain profile
is the set of XML descriptor files that are required for
an SCA compliant system.
Models are the basis of the software development effort.
CE allows team members to share model elements.
The model elements that are created at the beginning
of the development process are passed on. At each
step, more information is added to the models.
Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process
Mark Hermeling, John Hogg, Francis Bordeleau
A software development process is vital for large-sized projects. Any project developing SCA compliant Waveforms
or Platforms falls in this category. Simply put, the process explains who does what when and how. Information
flow, artifact creation, and tool usage are important elements of a process, and this is where Zeligsoft Component
Enabler (CE) proves valuable. CE’s automation enables users to easily design, model, visualize, and author artifacts
which, if maintained manually, would be expensive and error-prone.
This paper demonstrates the use of CE in a software development process. Because every project defines its
own specific process, this paper does not attempt to describe the details of an overall process. It instead focuses
on the description of the different roles involved in a process and on how CE can be used to support these roles.
CE models focus on how components communicate.
They do not express how components should be
implemented. Implementation can be done by writing
source code by hand or through other modeling tools.
The SCA makes it easier to integrate COTS (Commercial
Off-the-Shelf) or third-party components. CE lets users
import these components into models through its XML
Import feature. The imported XML is automatically
checked for violations against the SCA standard in
the area of syntax and semantics.
The content of the CE models needs to be shared with
all the project stakeholders. This can be done through
the documentation generation capability of CE. This
capability generates documentation containing all the
content of the model. The documentation generation
is based on customizable templates.
3 PHASES, ROLES, AND RESPONSIBILITIES
Many software development projects already have their
own defined process. An example of a popular software
development process is the IBM Rational Unified Process.
This paper is intended to be process agnostic. We will
use high-level general development phases and roles
to illustrate the use of CE. The content of this paper
can be adapted to any software development process
for projects using CE.
The phases in our simplified process are requirements,
design, implementation, and testing. In an iterative
process, these phases are traversed multiple times
(once for each iteration) for a single release. Each
iteration brings the delivered product closer to the full
set of functionality required. See section 9 for a more
detailed discussion on the use of CE in an iterative
Work in each of the phases is done by the software
development team. People on the team have different
roles. Each role has responsibilities, and consumes
and creates artifacts. Figure 1 illustrates how the roles
relate to the phases in a specific iteration.
This paper focuses on the use of CE in the different roles
and phases. From an SCA perspective, the requirements
phase does not benefit from visual modeling. It is,
therefore, not covered here.
Figure 1: Phases and roles
requirements design implementation test
Zeligsoft CE™ in Action
The design phase prepares the blueprints for the
development of the software. It starts with a high-level
design where the responsibilities of the system are
divided into smaller, more manageable modules. The
system architect is responsible for this high-level
The high-level design or architecture model is then
given to the application engineer and the platform
engineer for further elaboration.
The platform engineer is responsible for the SCA plat-
form. The platform includes the actual system hard-
ware and the software environment required to use
this hardware: RTOSes (Real-Time Operating Systems),
device drivers, communication middleware (CORBA
ORBs), and the SCA Core Framework implementation,
which provides standard interfaces to the platform and
The application engineer is responsible for the SCA
application architecture. The application includes all the
components that provide functionality to the system,
including their interconnections and their connections
to devices on the platform.
The component developer is responsible for the
implementations of the components and maintaining the
model with respect to those implementations. There are
usually two different teams of component developers,
one team for the application components and one
team for the platform components.
The component developers on the platform team
work at the hardware level. They write code for GPPs
(General-Purpose Processors), DSPs (Digital Signal
Processors), FPGAs (Field-Programmable Gate Arrays),
and the device drivers that can access these devices.
The component developers on the application team
work at higher levels of abstraction. Their code uses
the components delivered by the platform team and
builds upon their services. The components provide
the adaptable functional behavior for the system.
The system tester is responsible for verifying the
quality of the integrated system, which includes testing
of all valid deployments of application components to
the platform. The system tester tests the system as a
whole, as opposed to the component developer who
performs unit testing of functionality on a limited number
4 SYSTEM ARCHITECT
4.1 Role Introduction
The system architect is responsible for deciding on the
division of the application into components. The system
architect creates the layout for the main software
components (the application) and the main platform
components (the node, including the executable devices).
This results in an early high-level model of the run-time