54,899 research outputs found
Application area for multiple software product lines in automotive development
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
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
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
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
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
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
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
- …