Reengineering: An Engineering Problem

This paper discusses a plan that addresses how the Software Engineering Institute (SEI) may assist the Department of Defense (DoD) in reengineering its large software-intensive systems. This plan is based on a view of reengineering as an engineering problem to improve the cost-effective evolution of large software-intensive systems. This view of reengineering, which takes the whole software engineering process into account, fosters a growth path by leveraging promising emerging software engineering technologies. Reengineering also builds on the industry's improvement in its ability to manage the software engineering process, an accomplishment of SEI work in the Capability Maturity Model (CMM) and its key process areas

Modeling of System Families

Over their lifetime, systems exist in many forms, such as instances of a system deployed in different contexts or a system evolving over time. Variability may also occur in terms of functionality reflected in the domain architecture, nonfunctional properties (such as performance, reliability, and safety-criticality) that are realized in the runtime architecture, interfaces to the deployment environment with which the system interfaces, and mapping to computing platforms. The Society of Automotive Engineers (SAE) Architecture Analysis & Design Language (AADL) is an industry-standard, architecture-modeling notation specifically designed to support a component-based approach to modeling embedded systems. This technical note discusses how AADL can be used to model system families and configurations of system and component variants. It shows that AADL supports system families by providing component types that are used to specify component interfaces and multiple implementations for each component type. This report also shows that AADL uses properties to represent multiple dimensions of system variability ranging from variation through conditional compilation to variation through different sets of calibration parameters

Real-Time Application Development with OSEK: A Review of the OSEK Standards

OSEK is an abbreviation for a German term that translates to ?open systems and the corresponding interfaces for automotive electronics. OSEK OS is the operating system specification and OSEK COM is the communication specification. Both are application program interface (API) standards for automotive real-time application development. They are complemented by OSEK Implementation Language (OIL), a modeling language for describing the configuration of an OSEK application and operating system. This paper covers the SEI evaluation of these standards from the perspective of real-time application development. The SEI identified shortcomings in the description and semantics of certain services offered by the OSEK API. These shortcomings introduce unnecessary complexity to application developers and limit application portability. The SEI also identified the potential of OIL as an architectural modeling language to support design-time analyses, such as schedulability analysis. OIL's potential as a basis for generating both real-time OS data tables and an application runtime executive was examined. Utilizing OIL in this way simplifies application component development. Correct use of OSEK API functionality is then relegated to a generation tool that operates on OIL. Such improvements would facilitate practitioners' adoption of OSEK by reducing its perceived complexity

An Analysis Technique for Examining Integration in a Project Support Environment

In this paper we describe the use of a Project Support Environment (PSE) services reference model as an analysis technique that helps in describing, understanding, and comparing aspects of integration in a PSE. The model is briefly described, before being used as the basis for discussing a number of issues with regard to PSE integration. A major focus of this paper is a discussion of the interfaces of interest in a PSE—interfaces within a single service, between services, and between services and the PSE end-users. The paper concludes with a discussion of possible interpretations and developments of the model to suit different user requirements

Flow Latency Analysis with the Architecture Analysis and Design Language (AADL)

Control system components are sensitive to the end-to-end latency and age of signal data. They are also affected by variation (jitter) in latency and age values due to different runtime configurations (i.e., sampling or data-driven signal processing pipelines, dissimilar communication mechanisms, partitioned architectures, and globally synchronous versus asynchronous hardware). This technical note introduces an analysis framework designed to calculate the end-to-end latency and age of signal stream data as well as their jitter. The latency analysis framework and calculations are illustrated in the context of an example model that uses the flow specification notation of the Architecture Analysis & Design Language (AADL). The report describes how this latency analysis capability can be used to determine worst-case end-to-end latency on system models of different fidelity and how it accounts for partitioned architectures. It also summarizes the worst-case end-to-end flow latency analysis capability provided by the Open Source AADL Tool Environment (OSATE) flow latency analysis plug-in

Managing Development of Very Large Systems: Implications for Integrated Environment Architectures

Version and configuration control are mechanisms for managing source code and system builds. In the development of very large systems, built by large teams, development management is the dominant factor. In this paper we examine management support for development through integrated environments and investigate the implications for environment architectures. We do so by defining a project scenario that is to be performed with integrated project support environments. The scenario has been carefully designed to not only determine the scope of management functionality provided by a particular environment, but also to probe implications for the architecture of environments. The implications discussed in this paper are: focus on user activities; the integration of project management and development support concepts; the ability to reinforce and avoid conflict with particular organizational models; the ability to support evolution and change of the product, environment, and organization; and the capability for adaptation and insertion into a work environment. The scenario is part of a methodology for evaluation of environments currently used at the Software Engineering Institute

The Project Management Experiment

This report covers a project management (PM) experiment, one of six experiments that examine different functional areas of ADA programming environments. The PM experiment was designed as part of the Evaluation of ADA Environments Project. This report describes the environment-independent part of the experiment: the activities covering the functional area, the evaluation criteria, and an experiment scenario to be performed on different environments. The experiment as it stands has been validated through internal and external review and through application to several environments that support project management

Dependability Modeling with the Architecture Analysis & Design Language (AADL)

The Society for Automotive Engineers (SAE) recently published an Error Model Annex document (SAE AS-5506/1) to complement the SAE Architecture Analysis & Design Language (AADL) standard document (SAE AS5506) with capabilities for dependability modeling. The purpose of this report is to (a) explain the capabilities of the Error Model Annex and (b) provide guidance on the use of the AADL and the error model in modeling dependability aspects of embedded system architectures. The focus of the guidance is the creation of error model libraries and the instantiation of these error models on AADL architecture models. In that context, the report discusses modeling of error propagation, error filtering and masking, the interactions between error models and systems with operational modes, and modeling of repair activities

ASSIP Study of Real-Time Safety-Critical Embedded Software-Intensive System Engineering Practices

Modern weapon systems increasingly depend on real-time, safety-critical, embedded (RTSCE) software to achieve their mission objectives. In addition, these systems are experiencing far longer service lives than anticipated at their inception. Army weapon system developers are concerned that this combination of factors renders today's software acquisition and development practices insufficient to address the challenges of these software-intensive systems. To address the concern, the Army Strategic Software Improvement Program tasked the Carnegie Mellon Software Engineering Institute (SEI) to assess RTSCE software-intensive systems issues and develop recommendations. The findings of phase one of that study are presented in this report: (1) industry is driving the development of tools for model-based engineering to meet the needs of RTSCE system development, and (2) many opportunities exist for the U.S. Department of Defense (DoD) to gain experience and advance the transition of these tools into DoD programs

What’s New in V2 of the Architecture Analysis & Design Language Standard?

<p>This report provides an overview of changes and improvements to the Architecture Analysis & Design Language (AADL) standard for describing both the software architecture and the execution platform architectures of performance-critical, embedded, real-time systems. The standard was initially defined in the document SAE AS-5506 and published in November 2004 by SAE International (formerly the Society of Automotive Engineers). SAE International published the revised language, known as AADL V2, in January 2009. Feedback from users of the standard guided the plan for improvements. Their experience and suggestions resulted in the addition of component categories to better represent protocols as logical entities (virtual bus), scheduler hierarchies and logical time partitions (virtual processor), and a generic component (abstract). The revisions also led to the abilities to (1) explicitly parameterize component declarations to better express architecture patterns, (2) specify multiple instances of the same component in one declaration (component array) and corresponding connection patterns, (3) set visibility rules for packages and property sets that access other packages and property sets, (4) specify system-level mode transitions more precisely, and (5) use additional property capabilities including property value records.</p