54,899 research outputs found

    Application area for multiple software product lines in automotive development

    Get PDF
    International audienceSince today’s well known software product lines (SPL) approaches [1] [2] [4] [5] [6] [7] [8] [9] [12] focus on one single SPL, a methodology for connection and adjustment of multiple product lines is needed. The paper will shortly survey existing processes and methods e.g. FODA [4] for product lines and show adaptations to automotive industry. The focus of the paper will be an adapted process for automotive functional development, which is based on multiple software product lines (MSPL) and particularly regards customer-supplier relationship. It will propose a general SPL interface to manage using MSPL. The interface consists of a SPL Interface Methodology which defines steps for the adjustment of two or more different SPLs as well as a data interface (SPL Interface Data) which defines a data format for the exchange between different SPL tools. The SPL adjustment is demonstrated with a case study of an imaginary advanced driver assistance system called mobilSoft Adaptive Cruise Control (MCC), which consists of three product lines, one for the whole MCC and two for the subsystems linear tracking and traverse control

    Automatic allocation of safety requirements to components of a software product line

    Get PDF
    Safety critical systems developed as part of a product line must still comply with safety standards. Standards use the concept of Safety Integrity Levels (SILs) to drive the assignment of system safety requirements to components of a system under design. However, for a Software Product Line (SPL), the safety requirements that need to be allocated to a component may vary in different products. Variation in design can indeed change the possible hazards incurred in each product, their causes, and can alter the safety requirements placed on individual components in different SPL products. Establishing common SILs for components of a large scale SPL by considering all possible usage scenarios, is desirable for economies of scale, but it also poses challenges to the safety engineering process. In this paper, we propose a method for automatic allocation of SILs to components of a product line. The approach is applied to a Hybrid Braking System SPL design

    Boundary Objects and their Use in Agile Systems Engineering

    Full text link
    Agile methods are increasingly introduced in automotive companies in the attempt to become more efficient and flexible in the system development. The adoption of agile practices influences communication between stakeholders, but also makes companies rethink the management of artifacts and documentation like requirements, safety compliance documents, and architecture models. Practitioners aim to reduce irrelevant documentation, but face a lack of guidance to determine what artifacts are needed and how they should be managed. This paper presents artifacts, challenges, guidelines, and practices for the continuous management of systems engineering artifacts in automotive based on a theoretical and empirical understanding of the topic. In collaboration with 53 practitioners from six automotive companies, we conducted a design-science study involving interviews, a questionnaire, focus groups, and practical data analysis of a systems engineering tool. The guidelines suggest the distinction between artifacts that are shared among different actors in a company (boundary objects) and those that are used within a team (locally relevant artifacts). We propose an analysis approach to identify boundary objects and three practices to manage systems engineering artifacts in industry

    Supporting the automated generation of modular product line safety cases

    Get PDF
    Abstract The effective reuse of design assets in safety-critical Software Product Lines (SPL) would require the reuse of safety analyses of those assets in the variant contexts of certification of products derived from the SPL. This in turn requires the traceability of SPL variation across design, including variation in safety analysis and safety cases. In this paper, we propose a method and tool to support the automatic generation of modular SPL safety case architectures from the information provided by SPL feature modeling and model-based safety analysis. The Goal Structuring Notation (GSN) safety case modeling notation and its modular extensions supported by the D-Case Editor were used to implement the method in an automated tool support. The tool was used to generate a modular safety case for an automotive Hybrid Braking System SPL

    Why and How Your Traceability Should Evolve: Insights from an Automotive Supplier

    Full text link
    Traceability is a key enabler of various activities in automotive software and systems engineering and required by several standards. However, most existing traceability management approaches do not consider that traceability is situated in constantly changing development contexts involving multiple stakeholders. Together with an automotive supplier, we analyzed how technology, business, and organizational factors raise the need for flexible traceability. We present how traceability can be evolved in the development lifecycle, from early elicitation of traceability needs to the implementation of mature traceability strategies. Moreover, we shed light on how traceability can be managed flexibly within an agile team and more formally when crossing team borders and organizational borders. Based on these insights, we present requirements for flexible tool solutions, supporting varying levels of data quality, change propagation, versioning, and organizational traceability.Comment: 9 pages, 3 figures, accepted in IEEE Softwar

    Evaluation of Variability Concepts for Simulink in the Automotive Domain

    Get PDF
    Modeling variability in Matlab/Simulink becomes more and more important. We took the two variability modeling concepts already included in Matlab/Simulink and our own one and evaluated them to find out which one is suited best for modeling variability in the automotive domain. We conducted a controlled experiment with developers at Volkswagen AG to decide which concept is preferred by developers and if their preference aligns with measurable performance factors. We found out that all existing concepts are viable approaches and that the delta approach is both the preferred concept as well as the objectively most efficient one, which makes Delta-Simulink a good solution to model variability in the automotive domain.Comment: 10 pages, 7 figures, 6 tables, Proceedings of 48th Hawaii International Conference on System Sciences (HICSS), pp. 5373-5382, Kauai, Hawaii, USA, IEEE Computer Society, 201

    Clafer: Lightweight Modeling of Structure, Behaviour, and Variability

    Get PDF
    Embedded software is growing fast in size and complexity, leading to intimate mixture of complex architectures and complex control. Consequently, software specification requires modeling both structures and behaviour of systems. Unfortunately, existing languages do not integrate these aspects well, usually prioritizing one of them. It is common to develop a separate language for each of these facets. In this paper, we contribute Clafer: a small language that attempts to tackle this challenge. It combines rich structural modeling with state of the art behavioural formalisms. We are not aware of any other modeling language that seamlessly combines these facets common to system and software modeling. We show how Clafer, in a single unified syntax and semantics, allows capturing feature models (variability), component models, discrete control models (automata) and variability encompassing all these aspects. The language is built on top of first order logic with quantifiers over basic entities (for modeling structures) combined with linear temporal logic (for modeling behaviour). On top of this semantic foundation we build a simple but expressive syntax, enriched with carefully selected syntactic expansions that cover hierarchical modeling, associations, automata, scenarios, and Dwyer's property patterns. We evaluate Clafer using a power window case study, and comparing it against other notations that substantially overlap with its scope (SysML, AADL, Temporal OCL and Live Sequence Charts), discussing benefits and perils of using a single notation for the purpose
    • …
    corecore