Boeing Sponsored Class Project With
Computer Science Department of
Purdue University
CS406/407
1999/2000
Class Project
Contact:
Robert A.
Byrne, Jr.
Department
Manager, Avionics Software Engineering
Military
Aircraft & Missile Systems
The Boeing
Company
PO Box 516,
Mailcode S270-4235
St. Louis,
MO 63166-0516
314-234-8734
1 Project Overview................................................................................................ 3
2 Functionality Overview.................................................................................. 4
3 Modeling.................................................................................................................. 5
3.1 Component Configuration....................................................................... 5
3.1.1 Overview........................................................................................................ 5
3.1.2 Event Configuration................................................................................ 5
3.1.3 Persistence Configuration.................................................................... 6
3.1.4 Concurrency Configuration................................................................ 7
3.1.5 Real-time Information Configuration............................................. 7
3.2 Process Configuration............................................................................... 8
3.2.1 Process Configuration Overview....................................................... 8
3.2.2 Process Specification............................................................................... 8
3.2.3 Component Creation Definition........................................................... 8
3.2.4 Event Consumer Definition.................................................................... 9
3.2.5 Supplier Dependency Definition......................................................... 10
3.3 Build Definition............................................................................................ 11
3.3.1 Scenarios...................................................................................................... 11
3.3.2 Requirements.............................................................................................. 11
3.4 Additional Requirements....................................................................... 12
3.4.1 Operational Environment.................................................................... 12
3.4.2 Extensibility............................................................................................... 12
4 Build Generation............................................................................................... 13
4.1 Component Identifier Output............................................................... 13
4.1.1 Component Identifier Requirements................................................ 13
4.1.2 Component Identifier Sample Output.............................................. 13
4.2 Configuration Info Source Code Output....................................... 15
4.2.1 Configuration Info Source Code
Requirements......................... 15
4.2.2 Configuration Info Source Code Sample
Output....................... 15
5 Definitions............................................................................................................. 18
1
Project Overview
The Phantom Works
division of The Boeing Company is the research and development arm of the
corporation and is tasked with strengthening the Boeing core competencies
through the development and transition of innovative technologies, tools,
processes, and products. The Bold
Stroke Program within Phantom Works is tasked with developing
faster/better/cheaper avionic systems and, especially, the software that is
embedded in those systems (known as Operational Flight Programs or OFPs). In order to support the new Object-Oriented/C++/multi-processor
architecture being developed by the Bold Stroke Team, additional tools will be
required to improve the productivity of the avionics software develop process.
Boeing needs a graphical tool for laying out the placement of components on multiple processor boards and then auto-generating build and configuration files (autocode and configuration tables). The commercial name for this type of software is an application builder. Application builders, which are gaining popularity, present software components, that are usually part of an application library, to the user which he/she then wires together to create an application. The best example of this commercially is the family of application builders that work with Java components. Visual Basic probably also qualifies.
The key to building application builders is basing them on a common underlying component definition, e.g., JavaBeans or equivalent. The need, in this case, arises for a custom application because there is currently no commercial standard for real-time avionics components equivalent to JavaBeans or Visual Basic. Boeing has begun defining its own component definition on the Bold Stroke program, which could serve as a builder foundation.
2
Functionality
Overview
The function of
the Operational Flight Program Builder Tool (OBT) will be to allow avionic
software developers/builders to select OFP components from the library of
components and wire them together as appropriate for a particular hardware/test
configuration. An appropriate abstraction would be a design studio type
application that gives users the ability to perform the following functions:
·
Select OFP components from an OFP
Component library and inspect certain attributes of the component e.g.,
required rate of execution, event dependency, amount and rate of persistence
data, etc.
·
For each selected component, the
application will draw a visual representation, including “pins” representing
required configuration inputs
·
Define a process architecture build abstraction, i.e., number of
required separate processes
·
Place components within specific
processes abstractions
·
Allow the user to “wire” certain
component attributes together to satisfy component input requirements, perhaps
event dependencies.
·
Prompt the user for other required
configuration information, perhaps rate/thread/concurrency/persistence
information using component supplied configuration parameters (e.g. persistence
could be turned on or off, concurrency locks could be changed from
"null" to "instrumented", to "mutex", etc.).
· Allow the user to “build” the application, at which point the application would automatically generate files that support making an OFP suitable for execution on target hardware.
OBT user functions are divided into three major categories: Modeling, Build Generation, and Analysis. Modeling functions include configuring components from a component library, configuring processes as combinations of configured components and relationships, and configuring builds as combinations of configured processes. Build Generation functions are post-processing functions performed on a build defined by Modeling. Build files will include makefiles, configuration tables, and configuration software according to templates based on our component model, application architecture, and development environment. Analysis activities[1] include post-processing activities associated with determining the correctness of build defined by modeling.
In summary, the
OBT will accept for input a component library with multiple components
defined. The OBT will provide user
interfaces for the purposes of configuring components, assigning them to
processes, and combining processes into builds. Information used to define a build, including defined processes,
processes contents, component attribute definitions, and version numbers should
be storable on disk and available for later recall and edit. OBT output will be build and process
configuration files (typically tables, source code, and makefiles). Multiple users will perform OBT functions
simultaneously.
3 Modeling
The Modeling Function of the OBT enables the user to create a description of a build. The user is required to initiate this function before either Build Generation or Analysis functions.
3.1 Component Configuration
3.1.1 Overview
Each component will have several
attribute categories that require configuration as part of defining an OFP
build. Currently, Boeing has identified
the following attribute categories:
·
Event Delivery Types
·
Persistence
·
Concurrency
·
Component Attributes
·
Real-time Information
Each category has
one or more component attributes. Some
attributes must be configured prior to build.
Others are optional. Attributes
are either optional or required depending on a specification for another
attribute.
Attribute
categories will be represented within the OBT such that a user of the OBT can
select attributes for configuration per component. Attributes available for edit should be displayed for the
user. Configured attributes categories
should be distinguishable from unconfigured categories. User entries should be saved and available
for future edit.
All user entries
made within the component configuration window will modify the build master. The build master contains the default configuration, for all
attributes, for each component within a build.
Build master entries are therefore “class” wide, with respect to the
component definitions.
3.1.2 Event Configuration
Events are used within the OFP to
sequence control flow to the various components. Components can be event consumers, event suppliers, or both. Specifying the type of event
consumer/supplier to the Event Service influences event delivery overhead. In addition to consumer/supplier type,
consumers can also specify a relative importance. Importance is used to order event delivery to multiple consumers
all requesting the same event.
3.1.2.1 Scenarios
The user browses the components within the build specification to find components whose event configuration is to be updated. Components that publish events to other components are identified as Event Suppliers and the components that process these events are identified as Event Consumers. Components may be both Suppliers and Consumers for zero or more events. The user defines attributes of the events including the type of event and importance (see requirements below for detailed specification of legal values for type and importance).
3.1.2.2 Requirements
·
The OBT shall provide the user with
the ability to specify the type of event consumer applicable to the
component. Valid event consumer types
are UNSPECIFIED_CHANNEL, ERM, EFD, FULL_CHANNEL
·
The OBT shall provide the user with
the ability to specify the type of event supplier applicable to the component.
Valid event supplier types are UNSPECIFIED_CHANNEL, ERM, EFD, FULL_CHANNEL
·
The user display shall indicate
whether or not a specific component requires event consumer/supplier
specification.
·
The user display shall indicate
whether or not a component that requires event consumer/supplier specification
has been configured.
·
The user display shall indicate, for
the currently edited build, if the component event consumer/supplier
specification has been overridden.
·
The OBT shall provide the user with
the ability to specify the event importance applicable to the component. Valid event importances are VERY_LOW_IMPORTANCE,
LOW_IMPORTANCE, MEDIUM_IMPORTANCE, HIGH_IMPORTANCE, VERY_HIGH_IMPORTANCE.
3.1.3 Persistence Configuration
Persistence is used by the OFP to
store run-time state through power cycles of the mission computer. Only selected run-time state may be stored. If a portion of a component’s state is to be
stored, the user must specify several parameters associated with controlling
how the persistent store is completed.
Once specified, the component must be configured with several policies
that control when and how component state is copied to the store.
3.1.3.1 Scenarios
The user browses the components within the build specification to identify components that are required to have their state persisted. The application builder provides visual identification of the status of the persistence specification (unspecified, persistence enabled, or persistence disabled). The user may either disable persistence or enable persistence on any component. If a component is identified as persistent, the user elaborates a set of persistence attributes (described in further details in the requirements below).
3.1.3.2 Requirements
·
The OBT shall provide the user with
the ability to specify if persistence is enabled or disabled for the component.
·
For components with persistence
“disabled”, all other persistence related information will be selected to a
default.
·
For components with persistence
“enabled”, the user will be prompted for entries to the following fields:
·
Region ID: int
·
is Classified: Y/N
·
is Double Buffered: Y/N
·
default Save Method: USE_DEFAULT,
COPY_NOW_STORE_NOW_AND_WAIT, COPY_NOW_STORE_NOW, COPY_NOW_STORE_LATER,
COPY_NOW_STORE_NOW_FILTER
·
filter Time: float in microseconds
·
track Dirtyness: Y/N
·
save Rate ID: noRateID,
storeLaterRateID
·
The user display shall indicate
whether or not a specific component requires/supports persistence
specification.
·
The user display shall indicate
whether or not a component that requires/supports persistence specification has
been configured.
·
The user display shall indicate, for
the currently edited build, if the persistence specification has been
overridden.
3.1.4 Concurrency Configuration
Concurrency mechanisms, e.g.,
mutexes, are used by the OFP to control access to non-reentrant functions and
shared resources. Not all components
require mutexes, nor is it desirable to place mutexes where they are not needed
due to run-time overhead. The Boeing
Component Model supports tailoring of the type of mutex present within each
component.
3.1.4.1 Scenarios
The user browses the components defined within the build specification in order to identify components whose concurrency configuration is unspecified or needs to be modified. The user may define the type of lock that is used to manage the concurrency of the component. Legal values for the lock type are identified in the following requirements.
3.1.4.2 Requirements
·
The OBT shall provide the user with
the ability to specify the lock type for a component. Valid lock types are NULL_LOCK, THREAD_MUTEX,
RECURSIVE_THREAD_MUTEX, INSTRUMENTED_MUTEX
·
The user display shall indicate whether
or not a specific component requires/supports mutex specification.
·
The user display shall indicate
whether or not a component that requires/supports mutex specification has been
configured.
·
The user display shall indicate, if
for the currently edited build, if the mutex specification has been overridden.
3.1.5 Real-time Information Configuration
Currently, the Boeing Component Model supports the specification of component real-time information. This information is currently limited to specification of the component rate, but the information will be extended in the future.
3.1.5.1 Scenarios
The user browses the build configuration to identify components whose real-time information has not been specified or needs to be modified. The user modifies the rate attribute of the component to indicate at which rate the component is expected to run.
3.1.5.2 Requirements
·
The OBT shall provide the user with
the ability to specify the component rate for a component. Examples of valid component rates are 20Hz,
10Hz, 5Hz, 2Hz, and 1Hz.
·
The user display shall indicate
whether or not a rate specification has been configured.
·
The user display shall indicate, for
the currently edited build, if the component rate specification has been
overridden.
3.2 Process Configuration
3.2.1 Process Configuration Overview
Each build will have several
processes that require configuration.
Currently, Boeing has identified the following process attributes:
·
Component Instantiation &
Relationship Establishment
·
Event Dependencies
·
Supplier Dependencies
3.2.2 Process Specification
The first part of creating a
build is defining the processes that are present within the build. Processes represent address spaces within
the build. Each process has several components
defined within it. Currently, Boeing
allocates a single process to each physical CPU, as this is the model supported
by the underlying real-time operating system.
However, this should be considered a degenerate case.
3.2.2.1 Scenarios
The user may update the CPU architecture of the build by defining the CPUs present in a build. The user may create new processes for a build or delete existing processes from the build. Each process is defined by a unique name identifier and is assigned to a CPU within the build.
3.2.2.2 Requirements
·
The OBT shall provide the user with
the ability to create a representation of the target number of CPUs. The CPU architecture will be made up of one
or more CPUs.
·
The OBT shall provide the user with
the ability to create one or more process definitions. Each process shall be identified by a unique
name identifier.
·
The OBT shall provide the user with
the ability to assign one or more processes to each CPU within the CPU
architecture definition.
·
The OBT shall provide the user with
the ability to delete previously created processes.
3.2.3 Component Creation Definition
A process holds one or more
components. Components are developed
largely independent of the process within which it will execute. Within the Boeing initialization architecture,
a software component referred to as a configurator is hand-coded to create each of the
components defined to execute within a specific process. The configurator is the first component
within each process to execute during system initialization. The configurator performs several functions,
the first of which is directly or indirectly calling the constructor for each
component within the process.
3.2.3.1 Scenarios
The user may create new components and add them to the build specification. When creating a component, the user specifies a name for the component, a unique ID for the component, and optionally a role name for the component. The user also allocates the component to one or more processes. During the build specification the user may browse for a set of components and allocate them to processes. Before completing the build specification, the user will specify the order of creation of the components allocated to each process.
3.2.3.2 Requirements
·
The OBT shall provide the user with
the ability to view the list of library components registered for the current
build.
·
The OBT shall provide the user with
the ability to select components from this list for assignment within defined
processes.
·
The OBT shall allow the same component
to be assigned to more than one process simultaneously.
·
The OBT shall import all attributes for
components assigned to a specific process from the build master.
·
The OBT shall provide the user with
the ability to override any build master default component attribute. The override value(s) will only apply to
processes in which it is defined. These
modifications should therefore be considered “per instantiation” of the
component class.
·
The OBT shall provide the user with
the ability to graphically specify the order of component creation.
·
The OBT shall designate a unique
number representing the component ID
·
The OBT shall provide the user with
text entry fields for the component role
· The user display shall indicate, for the currently edited process, if the component creation information has been specified.
3.2.4 Event Consumer Definition
All components within a process
that are of type Event Consumer must register with the Boeing Event
Service. The Event Service defines
events to be a concatenation of a Supplier ID and an Event Type ID. The Event Service provides filtering
functions on events according to Supplier and Event Type Ids. Neither field is required. When registering as an event consumer, the
component may provide a Supplier ID for each event it wishes to receive. Events can be received from any component
assigned to any process within the build.
3.2.4.1 Scenarios
The user issues a request to the OBT to display event consumers, suppliers and their dependencies. The OBT graphically displays the event dependencies to the consumer. The user requests a list of library components assigned to a specific process that are configured as an Event Supplier. The user identifies additional event dependencies by "wiring" event suppliers to event consumers. The user may also delete any previously defined event dependencies.
3.2.4.2 Requirements
·
The OBT shall create a graphical
display of each subject component, which is configured as an Event Consumer
that shows its event supplier dependencies.
An appropriate metaphor is pins on an IC chip.
·
The OBT shall provide the user with
the ability to view the list of library components that 1) are assigned to any
process within the current build and 2) are configured as an Event Supplier.
·
The OBT shall provide the user with
the ability to "wire" the appropriate Event Supplier to an Event
Consumer "pin".
·
Event Consumers may have multiple
supplier event dependencies represented by multiple “pins”.
3.2.5 Supplier Dependency Definition
Components typically obtain their necessary input data by having references or pointers to supplier components on which they invoke “Get()” methods. These are typed polymorphic relationships to the façade classes of supplier components such that public member functions associated with supplier components are available. Relationships to other components are also used to control their operation and provide output data as appropriate.
3.2.5.1 Scenarios
The user issues a
request to the OBT to display data consumers, suppliers and their
dependencies. The OBT graphically
displays the data dependencies to the consumer being configured. The user requests a list of library components
assigned to a specific process that are configured as a Data Supplier. The user identifies the desired
supplier/consumer relationship by “wiring” the consumer to the supplier. The user may also delete any previously
defined data dependencies.
3.2.5.2 Requirements
·
The OBT shall create a graphical
display of each instantiated component that shows its supplier dependencies.
These supplier dependencies may either be fixed (e.g. a single supplier of a
given type) or variable in number (e.g. a variable linked list of suppliers of
a given type).
·
The OBT shall provide the user with
the ability to view the list of library components that are assigned to the
current process within the current build.
·
The OBT shall provide the user with
the ability to “wire” the appropriate Supplier(s) to a Consumer “pin”. Each
Consumer “pin” shall have an associated type that matches the wired Supplier
Component Type in order to be valid.
3.3 Build Definition
The purpose of the OBT is to
define OFP build models. Builds are
made up of a supplied component library, user-defined processes, a target
environment specification, and a default build master component configuration.
3.3.1 Scenarios
The user requests creation of a new
"build" model and specifies the name and location of the file used to
hold the specification data. The user
may also open previously defined build model files. A build master file will be
used by the OBT to obtain default values for component attributes that are not
specified by the user.
The user updates revision control
information (i.e., version number) when saving revised build files. The user
may override these defaults by providing specific attribute values.
The user modifies the default values
for components through the OBT. The
user saves the "build master" (default values) to a file that may be
used for future build specifications.
The user requests a summary of all
defined configuration information. The
OBT provides the user with a summary containing all of the configured
components, their version numbers, and their assigned processes.
3.3.2 Requirements
·
The OBT shall create a separate build
model file for each user-defined build.
·
The OBT shall provide
"standard" file editing
options to the user, i.e., open, save, save as, etc.
·
The OBT shall provide "standard"
edit options to the user, i.e., copy, paste, etc.
·
An OBT build model file shall contain
exactly one build definition.
·
The OBT shall provide the user with
the ability to specify a component library to associate with the build.
·
The OBT shall use the build master for
all component attributes not explicitly overridden.
·
The OBT shall associate a build
version number with each build.
·
The OBT shall provide a configuration
summary print capability. OBT
configuration summary printout shall contain at a minimum a list of the
configured components, the processes to which they are assigned, and associated
version numbers.
3.4 Additional Requirements
3.4.1
Operational Environment
·
The tool shall operate in a WindowsNT based workstation
3.4.2 Extensibility
·
Boeing anticipates the set of
component attributes present within the component model (and subject to
tailoring within the OBT) will grow. A
design goal of the OBT is that the tool be easily extended to support
additional attributes, i.e., designers should minimize decisions that limit
future extension to include additional attributes.
4 Build Generation
The purpose of the Build
Generation Function is to auto generate those files required to build and
initialize the OFP processes. Builds
are made up of a user supplied component library, user defined processes, and a
default build master component configuration.
4.1 Component Identifier Output
4.1.1 Component Identifier Requirements
The first step of organizing
configuration information is to associate identifiers with the instantiated
component names. This is done in the software by providing functions that are
named according to instantiated component names that return component
identifiers. Component identifiers have two fields associated with them: a
group identifier that corresponds with a façade class type within a particular
process and an item identifier that uniquely identifies each component
instantiation created from the class.
Within each section, preprocessor
directives (#ifdef) are used to compile only the appropriate entries into each
process. Anticipated future extensions would be:
·
to generate the associated code per software partitions
within the architecture (e.g. software layers)
·
to distinguish between components that are only known
locally within a process and those that are available remotely so that
instantiated components not available within a particular process neither
consume system resources nor provide cause for confusion
4.1.2 Component Identifier Sample Output
Following is the applicable
interface for the identifier class (UUIdentifier) for reference only:
typedef unsigned short UInt16Min;
typedef unsigned int UInt32Min;
class UUIdentifier
{
public:
UUIdentifier (XTypes::UInt16Min groupId, XTypes::UInt16Min itemId, const
char *name);
// This function returns the
full identifier.
XTypes::UInt32Min GetId () const;
// This function returns the
group identifier portion of
// the full identifier.
XTypes::UInt16Min GetGroupId () const;
// This function returns the
item identifier portion of the
// full identifier.
XTypes::UInt16Min GetItemId () const;
};
Following is the applicable
interface for the CComponentIdDefs namespace for the case where there are only
two instantiated components in the system, named “QAirframe” and
“QNavSteering”, and there are three processes named “CIO”, “GPP1”, and “GPP2”
for reference only:
class UUIdentifier;
namespace CComponentIdDefs {
enum ProcessName {
CIO,
GPP1,
GPP2
};
inline CComponentIdDefs::ProcessName
CComponentIdDefs::GetLocalProcessName()
{
#if defined PROCESS_CIO_MACRO
return
PROCESS_CIO;
#elif PROCESS_GPP1_MACRO
return
PROCESS_GPP1;
#elif PROCESS_GPP2_MACRO
return
PROCESS_GPP2;
#endif
};
#endif
Following is the associated
generated identifier output:
Header:
#include "CComponentIdDefs.h"
class UUIdentifier;
class CComponentIds {
public:
static const UUIdentifier&
GetAirframeId(CComponentIdDefs::ProcessName =
CComponentIdDefs::GetLocalProcessName());
static const UUIdentifier&
GetNavSteeringId(CComponentIdDefs::ProcessName =
CComponentIdDefs::GetLocalProcessName());
};
Body:
#include "CComponentIds.h"
#include "UUIdentifier.h"
namespace {
const UUIdentifier qAirframeId [] = {
UUIdentifier ( 0, 0, "component not in process CIO"),
UUIdentifier ( 0x4801, 0x0008, "qAirframe(GPP1)"),
UUIdentifier ( 0x6801, 0x0008, "qAirframe(GPP2)")
};
const UUIdentifier qNavSteeringId [] = {
UUIdentifier ( 0, 0, "component not in process CIO"),
UUIdentifier ( 0x480e, 0x0008, "qNavSteering(GPP1)"),
UUIdentifier ( 0, 0, "component not in process GPP2")
};
};
const UUIdentifier&
CComponentIds::GetAirframeId(CComponentIdDefs::ProcessName process)
{
return qAirframeId [process];
}
const UUIdentifier& CComponentIds::GetNavSteeringId(CComponentIdDefs::ProcessName
process)
{
return qNavSteeringId [process];
}
4.2 Configuration Info Source Code Output
4.2.1 Configuration Info Source Code Requirements
Additional configuration
information is stored and indexed based on the assigned identifiers. Separate
structures are defined for each component attribute category.
4.2.2 Configuration Info Source Code Sample Output
As an example of configuration
data, consider event configuration data from section 3.1.2. An associated set of types might be:
enum EventServiceType {
UNSPECIFIED_CHANNEL, ERM, EFD, FULL_CHANNEL
}
enum EventImportanceType {
VERY_LOW_IMPORTANCE, LOW_IMPORTANCE, MEDIUM_IMPORTANCE, HIGH_IMPORTANCE,
VERY_HIGH_IMPORTANCE
}
Struct EventConfigInfo {
EventServiceType consumerType_;
EventImportanceType consumerImportance_;
EventServiceType supplierType_;
};
Given this definition, the
configuration info specified for each instantiated component must be generated.
For example:
Header:
// Instantiation of STL vector
template.
typedef std::vector<UUIdentifier>
IdVector;
namespace CComponentInfoData {
// Accessors for Event Configuration Info.
Const IdVector& GetEventServiceInfoIds ();
const EventConfigInfo* GetEventServiceInfo ();
// ... for other configuration data.
};
Body:
namespace {
UUComponentInfoServiceImpl::IdVector eventServiceInfoIds;
bool eventServiceInfoIdsInitialized = false;
const EventConfigInfo eventServiceInfo[] =
{
#ifdef PROCESS_CIO_MACRO // --------------------
#elif PROCESS_GPP1_MACRO // --------------------
{ FULL_CHANNEL, MEDIUM_IMPORTANCE, ERM }, // qAirframe
{ ERM, HIGH_IMPORTANCE, EFD } // qNavSteering
#elif PROCESS_GPP2_MACRO // --------------------
{ EFD, VERY_HIGH_IMPORTANCE, ERM } // qAirframe
#endif
};
};
const IdVector&
CComponentInfoData::GetEventServiceInfoIds () {
if (!EventServiceInfoIdsInitialized) {
eventServiceInfoIdsInitialized = true;
#ifdef PROCESS_CIO_MACRO // --------------------
#elif PROCESS_GPP1_MACRO // --------------------
eventServiceInfoIds.push_back (UUIdentifier ( 0x4801, 0x0008,
"qAirframe(GPP1)"));
eventServiceInfoIds.push_back (UUIdentifier ( 0x480e, 0x0008,
"qNavSteering(GPP1)"));
#elif PROCESS_GPP2_MACRO // --------------------
eventInfoIds.push_back (UUIdentifier ( 0x6801, 0x0008,
"qAirframe(GPP2)"));
#endif
}
return eventInfoIds;
}
const EventComponentInfo*
C8ComponentInfoData::GetEventInfo () {
return eventServiceInfo;
}
5 Definitions
Build – a build is the product of
the OBT. It contains a build master, a set of process definitions, and a
version specification.
Build
Master – a
build master is the default configuration for each component for each of the
major attributes. One build master
exists for a build file. The build
master is built from the user supplied component library. The build master can be selectively
overridden, per component, within process configuration.
Build
Version Definition – an attribute of the build that defines the version of the build and
the version of all components within the build
Component – an abstraction possessing
configuration attributes. A component
is the unit of composition within the OBT.
Component Attribute – behavior of a software
component capable of being tailored per build
Component
Attribute Category – a group of related component attributes, e.g., dependency
attributes, event attributes, etc
Component Library – a set of components that adhere to the
Boeing component model
Component
Version – a
pair of revision numbers from the .h and .cpp files corresponding to the
component definition
Configurator
– performs
the function of creating the entire running application by creating each
component and providing initialization information to each created
component. Much of the current
configurator is hand coded.
Configurator
Shell – a
“generic” configurator capable of working with OBT generated configuration
files to perform the same function as the custom configurator currently in use.
Dependency
Configuration Code – the C++ software generated by the OBT to initialize component
attributes, based on build information and suitable for execution by the
Configurator Shell.
Dependency
Attribute Category – Dependencies are server components upon which the subject component
invokes operations to access data.
Event Attribute Category – Events provide activation
control for components
Mutex Attribute Category – Mutexes control thread
access to shared resources
Persistence Attribute Category – Persistence attributes
control how the component accesses the persistent store
Process – an abstraction consisting of multiple
interconnected components that share an address space and common build files
Process Makefile -
instructions for guiding the build of a process
Real-time Info Attribute Category – Real-time info is a
collection of component attributes that specify how the component is executed
Enclosure 1
Component Model
