Component Enabler Best Practices: SCA Component Enabler Best Practices: SCA The place of Zeligsoft...

download Component Enabler Best Practices: SCA Component Enabler Best Practices: SCA The place of Zeligsoft Component

of 20

  • date post

  • Category


  • view

  • download


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.


    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.


    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.


    Figure 1: Phases and roles

    system architect

    application engineer

    platform engineer

    component developer

    system tester

    requirements design implementation test

    Zeligsoft CE™ in Action

  • 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.



    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