Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of...

20
Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling, John Hogg, Francis Bordeleau

Transcript of Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of...

Page 1: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

Component Enabler Best Practices: SCAThe place of Zeligsoft Component Enabler

within the SCA software development process

Mark Hermeling, John Hogg, Francis Bordeleau

Page 2: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,
Page 3: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

1 OVERVIEW

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: SCAThe 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.

1

Page 4: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

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

development workflow.

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.

2

Figure 1: Phases and roles

system architect

application engineer

platform engineer

component developer

system tester

requirements design implementation test

Zeligsoft CE™ in Action

Page 5: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

3.1 Design

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

design model.

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

its components.

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.

3.2 Implementation

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.

3.3 Testing

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

of components.

3

Page 6: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

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

architecture (see Figure 2). The run-time architecture

model covers who talks to whom while the system

executes. This model is used for discussions and

reviews. It communicates the ideas of the architecture

team to the rest of the development team.

This high-level design model is a preliminary model of

the software and hardware environment. The application

and platform engineers can evolve the high-level model

into a full fledged architecture.

In principle, an SCA waveform (application) is platform-

independent and its architecture does not depend on

the underlying hardware platform. In practice today, a

system architect has a very clear understanding of the

platform and may actually define it in parallel with

some sets of applications.

The system architect delivers the global architecture

document. This document describes the decisions

made in developing the architecture and is a critical

lifeline during the development of the system.

It is common to deliver the full functionality of the system

in different iterations. Each iteration adds extra pieces

of functionality to the system. The system architect

decides what parts of the functionality are delivered in

which iteration.

4.2 Workflows within CE

The system architect creates an early high-level

model of the run-time architecture in CE. This model

contains the components and some component

instances. If required, ports can be created on

components so communication can be indicated

between the component instances.

The model can be used as a basis for the architecture

document through the documentation generation facility.

A key part of the architect’s task is defining the protocols

between components. A protocol is an ordered set

of messages between two or more components. Each

message is defined by its operation, its parameters,

its return value, and whether it is synchronous or

asynchronous.

As discussed in section 9, the architect cannot and

should not attempt to define all details of every protocol,

except in the simplest of systems. Protocols evolve over

system development as new insights and requirements

are gained. However, the specification should be detailed

enough to guide the other roles in their evolution of

the protocols.

4

Figure 2: System Architect Responsibility

Page 7: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

4.3 Activities in CE

The list of activities performed by the system architect

using CE includes

Creating components definitions

Creating ports with or without interfaces on

component definitions and device definitions

Creating applications and component instances

Connecting component instances together

Creating platforms, nodes and device instances

Connecting device instances together

Defining protocols

Creating documentation

Delivering the model to the application

and platform engineers

4.4 Benefits of CE

The architect benefits from using CE mostly because

it makes communication easier and facilitates the

dissemination of information.

Creating the model in CE ensures that the system

is SCA compliant even this early in the development

cycle. The model is not expected to be complete at

this stage, and may generate validation warnings due

to under-specification (such as missing interfaces).

However, everything that is specified should be valid

when the architecture model is delivered to the appli-

cation and platform engineers.

The first model is created by the system architect. The

model can be used by the system architect to discuss

the architecture with the application and platform engi-

neers. The model can also be used to generate docu-

mentation and to keep the documentation in sync with

the model.

This is the start of a Model Driven Architecture® (MDA®)

approach to system development, where the model is

the primary source of communication, documentation,

and development.

5 APPLICATION ENGINEER

5.1 Role Introduction

The system architect defines the broad shape of an

entire system, but is not responsible for fine details,

such as the exact interfaces or protocols between

communicating components. The application engineer

builds on the foundations the system architect built

and turns it into a full fledged run-time architecture

model for the application engineer.

The application engineer describes how the various

components work together to deliver the full functionality

of the software. The description includes the division

of the application into components, the interfaces on

these components, and the interconnections between

them. All these artifacts, and the decisions that were

made in designing them, should be documented in

the architecture document.

The application engineer – together with the platform

engineer and the architect – is responsible for over-

seeing the evolution of the protocols, the interfaces

between components. The system architect has

defined the protocols at a high-level. The application

engineer and platform engineer are responsible for

refining these and adding detail.

5

Page 8: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

Figure 3 shows how the run-time architecture as defined

in CE is used. From the model, users can generate XML

that describes the application. The model can also be

used to derive the outline of the code that forms the

implementation. The code outline is the code that

glues the signal processing code and control code

into the SCA execution framework. The code outline is

delivered to the component developers, who use it to

build the SCA wrapper code. See also Figure 5.

After the application engineer has created the architecture

models, they can be handed down to the component

developers for further elaboration.

The application engineer is responsible for proper

integration of the application. Once the component

developer has created the implementations, the appli-

cation engineer needs to bring the entire system ‘up’.

This means the components need to be started within

the Core Framework on top of the platform. The inte-

grated components are used to prove functionality to

the system architect.

The application engineer plans the milestones that the

component developer needs to meet in delivering

capabilities. This is needed to ensure that the application

engineer can meet the milestones that were set for

him by the system architect.

5.2 Workflows within CE

The application engineer takes the SCA run-time

architecture part of the model from the system

architect and adds further detail to it, including

Creating components and instances

Defining the interfaces

Interconnecting the components

Creating inter-connections between the software

and the hardware architecture

Specifying attributes and relationships

The model can also be used to generate documenta-

tion, which needs to be integrated into the software

architecture document.

The application engineer – together with the architect –

may also decide to use existing components. Existing

components can be either legacy or COTS components.

Legacy components are components that were developed

for another project. COTS components are delivered

by a third party. These existing components can be

added to the model using the XML Import feature.

The application may need connections to platform ele-

ments. The platform elements are defined by the plat-

form engineer. The platform engineer should share

these model elements with the application engineer.

During the integration step, the application engineer

most likely integrates the components one by one into

a working system. The easiest way to do this is to

start with a partial application (a subset of the entire

application), and generate the descriptors. These

descriptors can then be downloaded to the target

and executed. Upon success the next component

can be added to the subset.

6

Figure 3: Application Engineer Responsibility

Page 9: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

Activities in CE

The list of activities performed by the application

engineer using CE includes

Adding attributes and properties to component

definitions

Adding ports and supported interfaces on

components

Adding external ports to the application

Creating dependencies from components to other

components and devices

Creating usesdevice relationships

Creating connectors between ports on components

Creating connectors between component instances

and devices

Specifying attributes on instances

Setting the assembly controller for the application

Importing existing or third party components and

applications

Validating and generating

Creating documentation

5.3 Benefits of CE

The application engineer benefits from the use of CE

through refining model elements. In the absence of tools,

the application engineer creates an entire design from

the beginning, based on the documents and diagrams

delivered by the system architect. When all stakeholders

use CE, there is continuity. The application engineer’s

design simply evolves the architecture delivered by the

architect. This both speeds up the design task and

reduces errors due to miscommunication.

The model provides one source for information.

Modifications to the architecture should be done

through the model. CE ensures that the entire model

space remains consistent and that derived artifacts,

such as descriptor files and documentation, can be

regenerated.

XML Import is an effective way to add COTS

components to the model. As an added benefit,

it also verifies the correctness of the XML that

accompanies the components.

CE’s XML Import feature helps users visualize and bet-

ter understand how COTS components can be inte-

grated into a project.

Documentation generation alleviates the tedious task

of creating documentation manually and makes it easy

to keep the documentation in sync with the model.

CE makes it easy to create subsets of the entire appli-

cation and generate the application. This is needed for

the software integration phase.

5.4 XML Generated

The XML descriptor files generated from the model

element under the application engineer’s control include

a SAD for every application

an SCD for every (SCA-compliant) component

an SPD for every component

PRF files where needed

7

Page 10: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

6 PLATFORM ENGINEER

6.1 Role Introduction

The responsibilities of the platform engineer are largely

the same as those of the application engineer, except

that the focus is on the platform. Only the major differ-

ences between the platform and application engineers

are indicated here.

The platform engineer is responsible for the correct

working of the execution environment. This includes

the physical hardware board, RTOS, CORBA, Core

Framework, board support package, the software

drivers – anything that makes the physical hardware

usable. The platform engineer gathers all the relevant

components for the platform and assembles them

into a node.

One big difference with the application engineer is that

in many projects, the hardware is obtained through a

third party vendor or a separate team. This means that

the platform engineer has a large number of third party

components to import, which need to be adapted for

the project.

The platform engineer is responsible for the logical

hardware elements. In the SCA these logical elements

are represented as devices. They are software repre-

sentations of the hardware elements. They communicate

with the other components in the system through well-

defined CORBA interfaces.

The platform engineer is also responsible for the Core

Framework and its configuration. The Core Framework

is typically delivered by a third party vendor or sepa-

rate team. The platform engineer is responsible for

integrating and configuring the Core Framework with

the rest of the system.

Once the component developer has created the

implementations for the platform, the platform engineer

is responsible for integrating them into a working platform.

This means that the devices need to be started together

with the Core Framework.

6.2 Workflows within CE

The platform engineer takes the platform part of the

model produced by the system architect and adds fur-

ther detail to it. The tasks of the platform engineer

include

Creating devices and instances

Defining the interfaces on devices

Instantiating devices onto the node

Interconnecting the devices

Specifying attributes and relationships

The model can also be used to generate documentation

for inclusion into the hardware architecture. Automated

generation makes it easy to keep the documentation,

the model, and the delivered XML synchronized.

The platform engineer is also responsible for choosing to

use existing or COTS components. These components

can be added to the model by importing existing XML.

8

Figure 4: Platform Engineer Responsibility

Page 11: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

The platform engineer can use CE in the integration

phase to quickly create subsets of the entire platform.

This simplifies incremental integration of the platform

components. Incremental integration is much easier

and more predictable than a “big bang” integration of

all components near the end of the process.

6.3 Activities in CE

The activities performed by the platform engineer

using CE include

Adding attributes and properties to device

definitions

Adding ports and supported interfaces on devices

Creating dependencies from devices to other devices

Creating connectors between ports on devices and

set the attributes

Creating connectors between devices and services

and the Core Framework

Specifying attributes on instances

Configuring the Core Framework components

Importing existing or third party XML

Validating and generating

Creating documentation

6.4 Benefits of CE

The platform engineer and application engineer see

many of the same benefits. Like the application engi-

neer, the platform engineer can build on the system

architect’s work to deliver a better design faster, with

fewer communication errors. Automated generation of

documentation delivers accurate descriptions quickly

and simplifies documentation maintenance as designs

evolve. Importing existing XML allows precious IP to be

adapted, reused and even improved through validation.

6.5 XML Generated

The XML descriptor files generated from the model

element under the platform engineer’s control include

a DCD for every node

an SCD for every device

an SPD for every device

PRF files where needed

DMD, DPD files where needed

7 COMPONENT DEVELOPER

7.1 Role Introduction

There are a number of different responsibilities for the

component developer role; however, the role is primarily

responsible for implementation of the application and

platform components.

The source code for components consists of three

parts: the wrapper code that deals with the CORBA and

Core Framework functionality, the signal processing

code, and the control code that guards the operation

of the component.

In most SCA projects, a team of component developers

is responsible for platform components, while separate

teams deliver the application component. The application

and platform domains are quite different and require

different skill sets. Both teams are covered as one role in

this paper, as their roles are similar from a CE perspective.

9

Figure 5: Build up of an SCA component

Page 12: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

Components can be implemented using modeling tools

such as Rational Rose or Microsoft Visio, in combination

with an object-oriented programming language such

as C++ for the application side. Alternatively, a Model-

Driven Architecture® (MDA®) tool such as IBM Rational

Rose RealTime, I-Logix Rhapsody or The MathWorks

Simulink can generate some or all of the source code.

The platform side would frequently rely on C for DSP

processors or VHDL for FPGAs.

During component implementation, protocols and

interfaces need to be revisited. The component developer

might discover inconsistencies or errors in the specifi-

cations. These need to be discussed with application

and platform engineers and resolved.

The component implementations must be unit-tested.

That is, the implementer of the functionality must

download the code to a test platform and run it. This

test platform can be an evaluation environment (such

as a Windows environment) or it can be the final target

environment.

Once the run-time architecture model and the imple-

mentations are complete, the component developer

is able to download and execute the application on

the target platform. A set of XML descriptors must

be generated for the domain profile. Users can either

generate XML descriptors for the entire model or for

a smaller subset.

The component developer is usually not responsible

for integration of the entire system. This is a task for

the application engineer, platform engineer and system

tester as discussed below. Integration is a team effort

as it spans multiple technologies. The platform and

application engineer are responsible for the integration

of all components into the SCA run-time framework.

They are responsible to get the application up and

running. The system integrator and tester is then

responsible for making sure the functionality of the

components match as designed in the architecture.

The component developer needs to create and main-

tain documentation. The documentation is needed by

many development processes to demonstrate how the

system is built and as input to design reviews.

7.2 Workflows within CE

The component developer takes the models from the

application engineer and platform engineer and builds

on them by adding detail for the implementations. The

detail that the component developer adds is related to

the specific properties of the implementation, including

stack size, entrypoint, and so forth.

To perform designer testing, the component developer

also creates test applications that contain a subsection

of the entire model space.

10

Figure 6: Artifacts for Component Developer

Page 13: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

7.3 Activities in CE

The list of activities performed by the component

developer using CE includes

Creating component and device implementations

in the model

Creating dependencies, properties and attributes

for the implementations with other developers and

engineers

Creating the physical implementations for the

components and devices in source code

Creating smaller applications for unit test

Downloading and unit testing in simulation or target

Creating documentation

7.4 Benefits of CE

A key benefit of using CE for the component developer

is that it provides guidance on using the SCA. The

SCA standard is complex. CE guides the developer

through the workflow of creating correct descriptors,

making it a more enjoyable and less error-prone task,

which results in higher quality software. It guarantees

that the details of descriptors are correct by construction.

Correct descriptors are important: they are at the

core of the deployment process. Debugging incorrect

descriptors during deployment is a time-consuming and

painful experience because of the limited debugging

capabilities of target environments.

The increased performance and quality means that

developers spend more time focusing on implementing

functionality, rather then debugging descriptor files. More

design, implementation, testing, and debugging cycles

result in higher quality software.

Making smaller models for testing becomes easier.

Creating an application is a simple drag-and-drop of

the components that need to be assembled.

Discussions between the platform team and the soft-

ware team can also benefit from the modeling tool:

they have a common vocabulary and models to use

as a basis for discussion.

7.5 XML Generated

The XML descriptor file generated from the model ele-

ments under the component developer’s control include

an SPD with information about the implementations

the PRF files that contain particular attributes that

are of importance to the implementation

Of course, the full set of XML files used and generated

by developers includes the files created by all roles

discussed above.

8 SYSTEM INTEGRATOR AND TESTER

8.1 Role Introduction

The system integrator and tester (or just “system tester”)

should not be forgotten in discussions about SCA

compliant applications. The system tester takes the

integrated application and verifies that the entire system

operates as specified in the requirements.

To do this the system tester needs to test the entire

system as one unit. However, testing frequently starts

with smaller sub-units of the application to facilitate

integration and test work required.

Ideally, interfaces and protocols would be so perfectly

specified that all components would work together the

first time. Currently, software engineering has not

reached such a state. Inevitably, there are problems. If

system integration is left until all components are com-

plete, major rework may be required to resolve these

problems, resulting in major delivery slips late in the

schedule. For this reason the system tester should

work with the development teams as early as possible

in the development cycle to verify partial functionality

and identify issues as soon as possible.

11

Page 14: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

System testers are usually not very familiar with the

SCA. They are focused on downloading software to

hardware and verifying that it is working. To do this,

they need to modify properties in the XML.

8.2 Workflows with CE

The system tester takes the executables and updated

models from the component developers for each

development milestone iteration and generates

descriptors. These descriptors are then downloaded

to the target and executed.

The test cases might require frequent XML modifica-

tions, which can be done through user-friendly, model-

based workflows.

8.3 Benefits of CE

CE helps system testers adhere to the SCA, so they

require less knowledge of it to accomplish their tasks.

The result is a reduction in the number of errors and

an increase in productivity.

The model also makes it easier for the system tester

to understand the pieces that participate in the func-

tionality under test.

9 ITERATIVE DEVELOPMENT

In highly structured development environments all

details of the application and platform designs – right

down to the details of interface operations and protocols –

could be the responsibility of the application and platform

engineers or even the system architect. In current

practice, the interfaces between communicating com-

ponents are often negotiated between the respective

component teams. This point deserves some discussion.

In a waterfall development process, each stage of

development is completed before handoff. In principle

this gives component development teams clear contracts

in the form of interfaces and protocols between these

interfaces. When teams deliver components that meet

these contracts they integrate immediately and smoothly.

While the vision is appealing, it does not reflect the

reality of complex systems. Architectures and designs

are driven by low-level reality. The details of a protocol

cannot be fully understood and specified until the details

of its participants’ behaviors are understood. For example,

when is a component ready to start receiving data?

The initialization steps may involve complex negotiations

with other components that are not visible in the system

architect’s high-level view. The component developers must

adapt protocols as system understanding progresses.

This is not a license for component developers to change

their interfaces at any time and without warning; late

interface churn is a clear symptom of a project in trouble.

Instead, industry-proven iterative approaches to interface

and protocol evolution should be applied. Interface and

protocol evolution should be monotonic, controlled,

and iterative.

12

Page 15: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

“Monotonic” means that the elaboration of a protocol

should start from a minimal base. The base (in the

form of messages, their parameters, and their ordering

within a protocol) may be partial, but the parts that are

present should be correct at every stage and nothing

should be removed or changed later. This perfect

approach is not achieved in practice as errors are dis-

covered and resolved, but non-monotonic changes

should be seen as defect correction, not iterative

development.

“Controlled” means that the developers of communi-

cating components do not own their interfaces. That’s

the responsibility of the application and platform engi-

neers, who retain their role through to delivery of the

completed application. The component developers

negotiate protocol evolution with each other, but they

must then deliver their proposed changes to the appli-

cation or platform engineer who approves them and

evolve the overall design to include them. The application

and platform engineers are responsible for the archi-

tectural integrity of their designs. The designs evolve

over time, but they must remain coherent and clean.

“Iterative” means that integration is not a one-step

process that happens at the end of the development

cycle. The system architect defined milestones for

system-wide functionality. The application and platform

engineers then defined milestones for partial system

integration. The component developers are responsible

for delivering these integrations.

The first partial integrations can demonstrate two

components establishing basic communication while

running on a host development system test environment

instead of the deployment target platform. Each inte-

gration milestone demonstrates increasing functionality

and complexity. The communication between two

components may expand to include new functionality

or use cases, or additional components may be

brought into the integrated system.

Simple integrations may be done entirely by component

development teams as they test their components against

those of their peers. In other environments, the system

tester is brought in from the very first integration, especially

if it is to be done on the deployment target instead

of a host environment. Early stakeholder involvement

improves the final product, so system tester participa-

tion is recommended for all integrations.

At a finer level, component developers have full

responsibility for their parts of the system. The

component developer is responsible for modeling the

SCA representation of the monolithic implementations

of the components.

SCA components also include externally visible properties.

Like protocols, these are part of the “contract” of the

component. They may be initially specified by the system

architect or added by an application or platform engineer.

The component contract may then be evolved and

elaborated by the component developer. While per-

forming their tasks, component developers might discover

that some information is missing in the model. This

missing information would be discussed with the

application or platform engineer. Together they would

enhance the model to include the missing information.

13

Page 16: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

10 EXAMPLE

As a sample workflow, consider an SCA compliant

Software Radio being developed by a company for

a third party customer. The customer has provided a

document containing the requirements for the radio.

These requirements are analyzed by the software

architect team, who come up with a number of possible

approaches to build the system. The team uses CE

to create a model for each of the approaches. CE’s

documentation generation feature can be used to

create documentation that details the benefits and

disadvantages of the different approaches.

In the end, the architect team decides on the best

architecture and picks one of the models as the seed

for further development. This model contains one

or more applications, a number of components and

component instances, a platform, one or more nodes,

a number of devices, and device instances. The

instances have some ports, likely without interfaces,

which are used to document who talks to whom

during runtime in the application. Further detail is

not required at this point.

The architecture team also comes up with a delivery

plan. The delivery plan documents the iterations that

the team needs to go through to deliver the full system

and the content that needs to be demonstrated at

each milestone.

The model and plan are then passed on to the appli-

cation and platform engineers. They evolve the model,

and add ports and properties to the components and

interfaces to the ports. They elaborate the application

and nodes to contain the proper connections. They

create properties on the components and devices and

relationships between them.

Where needed, the application and platform engineers

use the XML Import feature to integrate third party or

existing components into the model.

The application and platform engineers then create the

outline code that addresses the SCA and CORBA side

of the component and device functionality.

The architecture team keeps a close eye on the work

done by the application and platform engineers. They

frequently communicate and resolve conflicts; they

discuss the best way to push the project forward. The

model is used in this communication. By the end of

this stage, the model contains most of the content

needed for the system, with the exception of the infor-

mation for the implementations. The engineers ensure

that the information they enter into the model is SCA

compliant by using CE’s validation feature.

The application and platform engineers devise a delivery

plan for the component developers. This delivery plan

needs to be tuned to the delivery plan that was passed

down from the architects.

The application and platform engineers use CE’s

documentation generation feature to add information

about the work that they have delivered to the docu-

ments that the architect team started.

The component developers take the model and the

outline code delivered by the application and platform

engineers and they finalize them. They create the actual

core of the signal processing code and hook it up to the

CORBA and SCA wrappers. They provide the information

about the implementations (stack size, priority, entry-

point and so forth) into the model.

14

Page 17: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

Once implementations are available, the component

developers need to test the implementations by down-

loading them to a target and executing. This step fre-

quently requires the creation of test applications that

need to be SCA compliant. CE helps here too: the

component developers can modify the application

without the risk of invalidating the XML. CE ensures

everything remains valid.

Once the component developers have unit tested and

integrated the application, they send the entire appli-

cation to the system testers. This team downloads

the application to the final system and verifies the

functionality of the entire system. This occasionally

results in the need to modify the model to test the

system with different variables.

All the activities above are executed once for each iter-

ation. That is, the architects make a plan for all iterations,

create the model for the iteration and pass this down to

the application and platform engineers. The engineers

refine the model and make a plan for the component

developers. The component developers deliver the

implementations, which are integrated and passed to

the system testers to execute a system testing step.

Every iteration executes all phases in the development

process exactly once.

After an iteration, the result is assessed and used to

plan the next iteration. The iterations are executed a

bit staggered. That is, while the application and plat-

form engineers are executing iteration N the system

architects are preparing iteration N+1.

11 CONCLUSION

Tool automation makes work easier for the development

team. Zeligsoft CE’s benefits start at the architect role.

The architects can perform their work at the model level,

enabling them to discuss, evaluate, and communicate

their artifacts easily.

The work of the architects is passed down to the

engineers for further refinement and elaboration. Ease

of communication continues as the engineers can

easily understand what the architects have laid out.

And the architects can stay in touch with what the

engineers have done.

Sharing of models between the different roles is especially

important in an iterative approach. Iterative development

puts a higher strain on the development team in their

sharing of artifacts. Zeligsoft CE simplifies the sharing

through model import/export. The team can evolve the

model throughout all of the iteration and generate

descriptors when needed.

This is what MDA is all about: instead of generating,

sharing, and reviewing code, the model is used as the

basis of all work. This means that all stakeholders see

and use the same artifacts. This increases mutual

understanding between the roles and minimizes mis-

communication.

The model is then used to generate the XML artifacts

needed. This increases productivity dramatically. Users

have reported productivity increases by a factor of 10

or more. The time saved through automation can be

used for quality increasing activities, such as more

design iterations or to reduce time-to-market.

15

Page 18: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

XML generation from the model also reduces the

scope of knowledge that the individual team members

need to have of the SCA and its internal mechanics.

This reduced dependency on knowledge of the SCA

is especially important. Resources are scarce and

training is expensive. Certain development teams

may be conversant with the SCA, but many expert

engineers and component developers do not have

an in-depth knowledge of the SCA.

The XML generated from the model is correct by

construction. The tool-based approach provides

automatic validation of the adherence to the SCA

standard. This increase in quality is an important

aspect as correct XML files avoid significant time

loss during integration on the platform.

The XML Import feature facilitates understanding of

existing and third party XML. The XML can be brought

into the model, visualized, and then maintained from

there. During this process the XML is validated at the

syntax and semantic level.

The documentation generation feature eases the

documentation burden on the entire development

team. Documentation is a must in large projects.

Automation makes this feasible and enables the

development team to keep the documents up-to-date,

at minimum cost.

Zeligsoft CE delivers a modern automation environ-

ment to model, validate, and generate SCA compliant

applications.

12 REFERENCES

SCA

Software Communications Architecture

http://jtrs.army.mil/sections/technicalinformation/

fset_technical_sca.html

JTRS

http://jtrs.army.mil/

ZSFT-8

Developing SCA Compliant Systems

http://www.zeligsoft.com/papers/

zsft-008-Challenges.pdf

OMG

Object Management Group

http://www.omg.com

UML

Unified Modeling Language

http://www.uml.com

CORBA

http://www.corba.org

ZSFT

Zeligsoft Inc.

http://www.zeligsoft.com

RUP

IBM Rational Unified Process

http://www.ibm.com/software/awdtools/rup/

16

Page 19: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,
Page 20: Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of Zeligsoft Component Enabler within the SCA software development process Mark Hermeling,

Zeligsoft, Zeligsoft CE and Waveform Builder are trademarks of Zeligsoft Inc. All other trademarks are the property of their respective companies.Version 1.0Printed in Canada © Copyright 2005.

About Zeligsoft Inc.

Founded in 2002, Zeligsoft is the market leader in tools, which enable the design, deployment and

configuration of component-based embedded software. With a history of active participation in

the development and evolution of key component standards, Zeligsoft tools ensure the customer’s

applications and platforms comply with rigorous industry- and company-defined standards. With

support for automated compliance testing directly in the tools, Zeligsoft users can stay focused on

what they do best. Eliminating labor-intensive and error-prone tasks throughout the development

cycle, Zeligsoft helps customers deliver high-quality products to market faster. Zeligsoft CE™

(Waveform Builder™) is a proven software development tool for projects targeting the SCA.

Contact Information

Website: www.zeligsoft.com

Email: [email protected]

Toll-free (North America): 1-800-ZELIGSW (1-800-935-4479)

Direct dial: +1 819-684-9639