Controlling Concurrent Change - A Multiview Approach Toward Updatable Vehicle Automation Systems

The development of SAE Level 3+ vehicles [{SAE}, 2014] poses new challenges not only for the functional development, but also for design and development processes. Such systems consist of a growing number of interconnected functional, as well as hardware and software components, making safety design increasingly difficult. In order to cope with emergent behavior at the vehicle level, thorough systems engineering becomes a key requirement, which enables traceability between different design viewpoints. Ensuring traceability is a key factor towards an efficient validation and verification of such systems. Formal models can in turn assist in keeping track of how the different viewpoints relate to each other and how the interplay of components affects the overall system behavior. Based on experience from the project Controlling Concurrent Change, this paper presents an approach towards model-based integration and verification of a cause effect chain for a component-based vehicle automation system. It reasons on a cross-layer model of the resulting system, which covers necessary aspects of a design in individual architectural views, e.g. safety and timing. In the synthesis stage of integration, our approach is capable of inserting enforcement mechanisms into the design to ensure adherence to the model. We present a use case description for an environment perception system, starting with a functional architecture, which is the basis for componentization of the cause effect chain. By tying the vehicle architecture to the cross-layer integration model, we are able to map the reasoning done during verification to vehicle behavior

Architecture Information Communication in Two OSS Projects: the Why, Who, When, and What

Architecture information is vital for Open Source Software (OSS) development, and mailing list is one of the widely used channels for developers to share and communicate architecture information. This work investigates the nature of architecture information communication (i.e., why, who, when, and what) by OSS developers via developer mailing lists. We employed a multiple case study approach to extract and analyze the architecture information communication from the developer mailing lists of two OSS projects, ArgoUML and Hibernate, during their development life-cycle of over 18 years. Our main findings are: (a) architecture negotiation and interpretation are the two main reasons (i.e., why) of architecture communication; (b) the amount of architecture information communicated in developer mailing lists decreases after the first stable release (i.e., when); (c) architecture communications centered around a few core developers (i.e., who); (d) and the most frequently communicated architecture elements (i.e., what) are Architecture Rationale and Architecture Model. There are a few similarities of architecture communication between the two OSS projects. Such similarities point to how OSS developers naturally gravitate towards the four aspects of architecture communication in OSS development.Comment: Preprint accepted for publication in Journal of Systems and Software, 202

Interpreting "Systems Architecting"

The UK Chapter of the International Council on Systems Engineering (INCOSE UK) has commissioned research to illustrate the variety of usage of the terms architecture and architecting in the systems engineering community. These terms, though widely used, are rarely strictly defined, and the meaning attributed to the terms is not consistent even in formal publications. Using soft systems methodology, this research has analysed three published sources (MODAF, The Art of Systems Architecting by Maier and Rechtin, and ISO/IEC 42010), and conducted a series of interviews with systems architecting practitioners. Twelve contentious questions in systems architecting are discussed, and six perspectives on systems architecting presented, including three basic worldviews of the relationship between systems engineering and systems architecting. One model sees systems architecting as simply a rebranding of systems engineering to broaden its appeal with no change in content. Another model sees systems engineering restricted to its traditional processes, with systems architecting adding to systems engineering through external processes. The final model, and the most popular amongst the systems engineering community, sees systems architecting addressing shortcomings in traditional sequential lifecycle models by stretching the content of systems engineering to include new elements under the banner of systems architecting

Modelo arquitectónico desde la vista de información para apoyar la interoperabilidad de herramientas software que soportan la mejora de procesos de software

(Eng) Diverse software tools that support the software process improvement (SPI) not interoperate between them, that is to say, the exchange of information between the different tools is deficient, making it difficult to sequence and automatic re-use of information of SPI initiatives. In this article we present an architectural model from the information view to support the interoperability of software tools that support the stages of diagnosing the process and formulating improvements. The model establishes architecture that describes the type of information that can be exchanged these tools, as well as the structure of the data, their possible values, its semantics, and the restrictions imposed on the use and interpretation of such information. The architectural model is composed of a set of schemas, raised in conceptual form, which can be used by organizations that wish to develop software tools to interoperate, which provide support in a comprehensive way to diagnosing the process and formulating improvements of the SPI cycle. These schemas were evaluated using the qualitative method Focus Group.(Spa) La gran mayoría de herramientas software que soportan la mejora de procesos de software (SPI) no interoperan entre ellas, es decir, el intercambio de información entre las diferentes herramientas es deficiente, lo que dificulta la secuencia y reutilización automática de la información de las iniciativas de SPI. En este artículo presentamos un modelo arquitectónico desde la vista de información para apoyar la interoperabilidad de las herramientas software que soportan las etapas de Diagnóstico de procesos y Formulación de mejoras. El modelo establece la arquitectura que describe el tipo de información que pueden intercambiar estas herramientas, así como la estructura de los datos, sus posibles valores, su semántica, y las restricciones impuestas sobre la utilización e interpretación de dicha información. El modelo arquitectónico está constituido por un conjunto de esquemas planteados de forma conceptual, el cual puede ser utilizado por organizaciones que deseen desarrollar herramientas software que interoperen entre sí, las cuales brinden soporte de manera integral al Diagnóstico y Formulación del ciclo de SPI. Estos esquemas fueron evaluados utilizando el método cualitativo Focus Group

Behavior models for software architecture

Monterey Phoenix (MP) is an approach to formal software system architecture specification based on behavior models. Architecture modeling focuses not only on the activities and interactions within the system, but also on the interactions between the system and its environment, providing an abstraction for interaction specification. The behavior of the system is defined as a set of events (event trace) with two basic relations: precedence and inclusion. The structure of possible event traces is specified using event grammars and other constraints organized into schemas. The separation of the interaction description from the components behavior is an essential MP feature. The schema framework is amenable to stepwise architecture refinement, reuse, composition, visualization, and multiple view extraction. The approach yields a basis for executable architecture specification supporting early testing and verification, systematic use case generation, and performance estimates with automated tools.Consortium for Robotics and Unmanned Systems Education and Research (CRUSER)Consortium for Robotics and Unmanned Systems Education and Research (CRUSER)Approved for public release; distribution is unlimited.Approved for public release; distribution is unlimited

Design framework:redesign and new multi-user and testing support

The use of models to conceptualize systems is an important part of the process of building Cyber Physical Systems. While designing such systems, which are in general a multi-disciplinary activity, multiple designers are involved in the design decisions. Those decisions most likely are not captured and eventually forgotten after a period. The Design Framework is a visual modeling tool that aims to help architects and designers to documents the design rationales besides the design artifacts. It also helps them to collaborate to design a system together in a multidisciplinary environment. The Design Framework is at the level of a good prototype, but it is not ready for operational application by end-users in industry. One of the main issues with the Design Framework system is a sub-optimal code structure due to the lack of proper design and development approach. The assignment therefore is to reverse engineer the current design of the Design Framework and to come up with a new design. In order to maintain a system in use, presence of a test framework is necessary. Since the Design Framework is used in a multi-disciplinary environment, an improvement in the multi-user support of the system is also needed. In the first part of this report, the redesign of the Design Framework is discussed. To redesign the Design Frame-work, a number of refactoring techniques are applied. As a result, the code complexity is reduced, therefore the maintenance is increased. The second part of the assignment includes multi-user support and testability. The Design Framework manages the changes to design descriptions and maintains the history of the design artifacts. In this respect, it operates similar to version control systems. In the multi-user part of this report, the version controlling aspect of the Design Framework is described and synchronization of data for multi-user is elaborated. Finally some multi-user features are improved and developed. In the testability part of this report, the test support is described. A set of unit tests and end-to-end tests including the test for multi-user support is implemented. Provided test sets and the approaches used to setup test environment makes the Design Framework more stable and maintainable

A mapping study on documentation in Continuous Software Development

Context: With an increase in Agile, Lean, and DevOps software methodologies over the last years (collectively referred to as Continuous Software Development (CSD)), we have observed that documentation is often poor. Objective: This work aims at collecting studies on documentation challenges, documentation practices, and tools that can support documentation in CSD. Method: A systematic mapping study was conducted to identify and analyze research on documentation in CSD, covering publications between 2001 and 2019. Results: A total of 63 studies were selected. We found 40 studies related to documentation practices and challenges, and 23 studies related to tools used in CSD. The challenges include: informal documentation is hard to understand, documentation is considered as waste, productivity is measured by working software only, documentation is out-of-sync with the software and there is a short-term focus. The practices include: non-written and informal communication, the usage of development artifacts for documentation, and the use of architecture frameworks. We also made an inventory of numerous tools that can be used for documentation purposes in CSD. Overall, we recommend the usage of executable documentation, modern tools and technologies to retrieve information and transform it into documentation, and the practice of minimal documentation upfront combined with detailed design for knowledge transfer afterwards. Conclusion: It is of paramount importance to increase the quantity and quality of documentation in CSD. While this remains challenging, practitioners will benefit from applying the identified practices and tools in order to mitigate the stated challenges

Conceptual Systems Security Analysis Aerial Refueling Case Study

In today’s highly interconnected and technology reliant environment, systems security is rapidly growing in importance to complex systems such as automobiles, airplanes, and defense-oriented weapon systems. While systems security analysis approaches are critical to improving the security of these advanced cyber-physical systems-of-systems, such approaches are often poorly understood and applied in ad hoc fashion. To address these gaps, first a study of key architectural analysis concepts and definitions is provided with an assessment of their applicability towards complex cyber-physical systems. From this initial work, a definition of cybersecurity architectural analysis for cyber-physical systems is proposed. Next, the System Theory Theoretic Process Analysis approach for Security (STPA Sec) is tailored and presented in three phases which support the development of conceptual-level security requirements, applicable design-level criteria, and architectural-level security specifications. This work uniquely presents a detailed case study of a conceptual-level systems security analysis of a notional aerial refueling system based on the tailored STPA-Sec approach. This work is critically important for advancing the science of systems security engineering by providing a standardized approach for understanding security, safety, and resiliency requirements in complex systems with traceability and testability