Boeing/Purdue Class Project
CS 406/407
Fall 1999
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.