DOCSLIB.ORG

Capital Software Designer Applying an Architecture-Driven Approach to Onboard Software Design

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Capital Software Designer Applying an Architecture-Driven Approach to Onboard Software Design Siemens Digital Industries Software Capital Software Designer Applying an architecture-driven approach to onboard software design Executive summary Are you struggling with increasing onboard software volume and quality, a large number of variants and time-to-market pressure? This white paper reviews market trends that are transforming embedded software development in the automotive industry from an activity owned mostly by suppliers to a shared responsibility between original equipment manufacturers (OEMs) and suppliers. This digital transformation requires different processes and dedicated process support tooling. This white paper describes the digital transforma- tion challenge and suggests an architecture-driven approach for onboard software design based on the functionality of Capital Software Designer. siemens.com/swdesigner White paper | Capital Software Designer Abstract By 2020, the digital 200+ new electric and 10 million (semi) autono- $1.5 trillion in revenue 56% of new car buyers unitverse will reach 44 hybrid vehicle modles in mous cars on the road by from mobility and connec- would switch to a different zettabytes – a 10-fold the next three years 2020 tivity services by 2030 brand to get the technol- increase from 2013 ogy and feature the want Impact on Impact on Impact on Impact on Impact on All industries Mobility industry Automotive industry Automotive industry Automotive industry Source: IDC Source: Bloomberg Source: BI Intelligence Source: McKinsey and Company Source: Strategy& Figure 1: Megatrends transforming the automotive industry. The market trends in the automotive industry point manufacturers are using software to take more respon- towards connected, increasingly autonomous, highly sibility for the driving process. Classically clear-cut customized, electric and networked vehicles that are boundaries between infotainment and vehicle operat- perceived by younger generations more as “tablets on ing are blurring. wheels” than as traditional vehicles. These vehicles are Consequently, a collection of completely new functions expected to be extensible over their life through app increases the volume of onboard software by orders of purchases and installations, and offer passengers magnitude. A large portion of this software is critical for added-value services that are based on networks (see safety. Connecting vehicles to the internet opens it up figure 1). In addition, time-to-market pressure keeps to security threats, compromising vehicle integrity and building, and product complexity frequently leads to passenger confidentiality and safety. Due to constraints defects that aren’t detected until late in the process regarding weight, power, heat transfer and cabin space, when they are more expensive to fix, thus diminishing it is not possible to continue adding functions by adding the company’s profit. more electronic control units (ECUs). Thus, the industry Although software was used to run subordinate, low- will see a consolidation of software functions for large, level embedded control and entertainment functions in multi-core ECUs. As specified by AUTOSAR, dynamic the past, today it is used to: perceive and categorize its updates and extensions require a departure from static environment, coordinate the driving process in ECU images. Instead, manufacturers will need to move advanced driver assistance functions, provide telemetry toward a dynamic architecture more resembling gen- data to its manufacturer, receive over-the-air updates, eral-purpose information technology (IT) systems, as and obtain high levels of authority over route planning, specified by AUTOSAR Adaptive1. engine, gears, brakes and steering. In other words, White paper | Capital Software Designer specifications and acceptance criteria to suppliers; select and configure basic software layers, and sched- Speed Variability ule, integrate, build, verify, validate and qualify deliv- ered source code on a large scale. Since supporting the interaction with suppliers becomes tighter in the grey- Volume Quality box acquisition paradigm, the aerospace industry refers to it as the extended enterprise2. Adoption of this para- digm in the automotive industry is well documented in the contemporary literature3. Challenges in embedded automotive software. Developing onboard software in the extended enter- prise requires adequate tool support for connecting to typical application lifecycle management (ALM) systems Black-box paradigm such as Polarion ALM™ software. The same is true for: This trend contradicts the traditional approach in which most embedded onboard software has been developed • Connecting software variability to the product lines and integrated by suppliers into components or subsys- • Specifying systems and software requirements, tems. Acquiring and integrating engines, gearboxes, functionality and quality of service heating, ventilation and air conditioning (HVAC) sys- tems, seats and lighting systems are examples of such • Describing software architecture and its needed black-box systems. Integration happens simultaneously functional and timing properties in multiple domains, such as mechanics, thermal, • Creating supplier design specifications and integrating hydraulics, electrical, electromagnetic interference and delivered software artifacts buses. In this paradigm, embedded software is shipped • Verifying software compliance with specified as a nearly invisible part of the supplied subsystem, and properties it is not supposed to be frequently updated. Onboard software in this paradigm interacts with other onboard • Validating the software in its operational context software using well-defined, controlled bus signals. The • Qualifying software for production use black-box paradigm has allowed OEMs to focus on defining bus segments, packages and signals, but has • Reporting all results to the connected ALM system also led to a proliferation of ECUs in vehicles, creating Finally, large legacy code bases containing a company’s problems in terms of weight, consumed cabinet vol- valuable experience needs to be considered, as few ume, heat and power consumption. projects are start from scratch. Gray-box paradigm A gearbox designed by a supplier will deliver its soft- ware not as a dedicated embedded control unit, but as a binary executable the OEMs will integrate into a large- Digital transformation Adopting digitalization has enabled companies to scale ECU. This change in technology has a strong migrate existing and well-established processes from impact on the process organization between OEMs and paper-based artifacts to digital artifacts running on IT suppliers. OEMs are suddenly required to specify, order, infrastructure without changing processes. Digitalization integrate and validate software they had previously not has brought added value since with digital artifacts it is seen. This a gray-box paradigm, as the OEM will typi- easier to identify versions, re-vise, archive and search cally not develop the implementations. This process compared to paper artifacts. To a large extent, digitaliza- change is an example of digital transformation, as tion has preserved the relationships between product opposed to digitalization; see the inset box on the right. designers, manufacturers and their suppliers. Digital transformation is about realizing all the opportunities Migrating towards the gray-box approach requires digital technologies have to offer, including processes OEMs to take ownership of software requirements and and business models4. define software architectures, timing and memory needs; provide unambiguous implementation White paper | Capital Software Designer Architecture-driven design Automotive SPICE process reference model SWE.1 SWE.6 Software requirements Software qualification tests analysis SWE.2 SWE.5 Software architecture design Software integration and integration tests SWE.3 SWE.4 External development Integration and V&V Software detailed design and Software unit verifications units construction Figure 2: Key software engineering process groups of the Automotive SPICE model. Using Capital Software Designer enables you to defuse Capital Software Designer is focused on processes the potentially negative effects of increased software SWE.2 for software architecture design, SWE.4 for soft- volume, faster time-to-market, variant richness and ware unit verifications and SWE.5 for software integra- demand for higher quality by taking a uniquely compre- tion. It integrates with SWE.1 for software requirements hensive, architecture-driven, model-based approach to analysis and SWE.6 for software qualification tests embedded software design. It is tailored to the needs of through an integration with Polarion ALM, and with the extended enterprise, facilitating collaboration and software qualification. giving developers complete freedom of choice in their development environment. Frontloading defect detection and removal Architecture becomes useful if it is rich enough to be Enabling the extended enterprise analyzed before the first line of implementation code Capital Software Designer supports onboard software has been written to detect inconsistencies in the design. design in the extended enterprise, from software specifi- To this end, Capital Software Designer provides data cation and qualification to tightly integrated services types enriched by physical units, data-flow architecture targeting software engineering process groups of the enriched by formal contracts, and block annotations Automotive Software Process Improvement
Load more

Recommended publications
  • Budgen, Software Design Methods
    David Budgen The Loyal Opposition Software Design Methods: Life Belt or Leg Iron? o software design methods have a correctly means “study of method.”) To address, but future? In introducing the January- not necessarily answer, this question, I’ll first consider D February 1998 issue of IEEE Software,Al what designing involves in a wider context, then com- Davis spoke of the hazards implicit in pare this with what we do, and finally consider what “method abuse,”manifested by a desire this might imply for the future. to “play safe.”(If things go well, you can take the credit, but if they go wrong, the organization’s choice of method can take the blame.) As Davis argues, such a THE DESIGN PROCESS policy will almost certainly lead to our becoming builders of what he terms “cookie-cutter, low-risk, low- Developing solutions to problems is a distinguish- payoff, mediocre systems.” ing human activity that occurs in many spheres of life. The issue I’ll explore in this column is slightly dif- So, although the properties of software-based systems ferent, although it’s also concerned with the problems offer some specific problems to the designer (such as that the use of design methods can present. It can be software’s invisibility and its mix of static and dynamic expressed as a question: Will the adoption of a design properties), as individual design characteristics, these method help the software development process (the properties are by no means unique. Indeed, while “life belt” role), or is there significant risk that its use largely ignored by software engineers, the study of the will lead to suboptimum solutions (the “leg iron”role)? nature of design activities has long been established Robert L.
    [Show full text]
  • Software Design Document 1
    SOFTWARE DESIGN DOCUMENT 1. Introduction The following subsections of the Software Design Document (SDD) should provide an overview of the entire SDD. 1.1 Purpose This subsection should explain the purpose of the SDD and specify the intended audience for it. The SDD described the software structure, software components, interfaces and data necessary for the implementation phase. Each requirement in the SRS should be traceable to one or more design entities in the SDD. 1.2 Scope This subsection should relate the design document to the SRS and to the software to be developed. 1.3 Definitions, Acronyms and Abbreviations This subsection should provide the definitions of all terms, acronyms and abbreviations that are used in the SDD. 2. References This subsection should provide a complete list of all documents referenced in the SDD. It should identify these references by title, report number, date and publishing organization. It should also specify the sources from which these references are available. 3. Attributes of Design Entities There are some attributes common to all entities, regardless of the approach utilized, whether procedural or object-oriented. These are used in subsections 4 and later. 3.1 Identification The name of the entity should be specified. Two entities should not have the same name. 3.2 Type The type attribute should describe the nature of the entity. It may simply name the kind of entity, such as subprogram, module, procedure, process, data item, object etc. Alternatively, design entities can be grouped, in order to assist in locating an entity dealing with a particular type of information.
    [Show full text]
  • Software Design Document (SDD) Template
    Software Design Document (SDD) Template Software design is a process by which the software requirements are translated into a representation of software components, interfaces, and data necessary for the implementation phase. The SDD shows how the software system will be structured to satisfy the requirements. It is the primary reference for code development and, therefore, it must contain all the information required by a programmer to write code. The SDD is performed in two stages. The first is a preliminary design in which the overall system architecture and data architecture is defined. In the second stage, i.e. the detailed design stage, more detailed data structures are defined and algorithms are developed for the defined architecture. This template is an annotated outline for a software design document adapted from the IEEE Recommended Practice for Software Design Descriptions. The IEEE Recommended Practice for Software Design Descriptions have been reduced in order to simplify this assignment while still retaining the main components and providing a general idea of a project definition report. For your own information, please refer to IEEE Std 1016­1998 1 for the full IEEE Recommended Practice for Software Design Descriptions. 1 http://www.cs.concordia.ca/~ormandj/comp354/2003/Project/ieee­SDD.pdf Downloaded from http://www.tidyforms.com (Team Name) (Project Title) Software Design Document Name (s): Lab Section: Workstation: Date: (mm/dd/yyyy) Downloaded from http://www.tidyforms.com Software Design Document TABLE OF CONTENTS 1. INTRODUCTION 2 1.1 Purpose 2 1.2 Scope 2 1.3 Overview 2 1.4 Reference Material 2 1.5 Definitions and Acronyms 2 2.
    [Show full text]
  • Software Reliability and Dependability: a Roadmap Bev Littlewood & Lorenzo Strigini
    Software Reliability and Dependability: a Roadmap Bev Littlewood & Lorenzo Strigini Key Research Pointers Shifting the focus from software reliability to user-centred measures of dependability in complete software-based systems. Influencing design practice to facilitate dependability assessment. Propagating awareness of dependability issues and the use of existing, useful methods. Injecting some rigour in the use of process-related evidence for dependability assessment. Better understanding issues of diversity and variation as drivers of dependability. The Authors Bev Littlewood is founder-Director of the Centre for Software Reliability, and Professor of Software Engineering at City University, London. Prof Littlewood has worked for many years on problems associated with the modelling and evaluation of the dependability of software-based systems; he has published many papers in international journals and conference proceedings and has edited several books. Much of this work has been carried out in collaborative projects, including the successful EC-funded projects SHIP, PDCS, PDCS2, DeVa. He has been employed as a consultant to industrial companies in France, Germany, Italy, the USA and the UK. He is a member of the UK Nuclear Safety Advisory Committee, of IFIPWorking Group 10.4 on Dependable Computing and Fault Tolerance, and of the BCS Safety-Critical Systems Task Force. He is on the editorial boards of several international scientific journals. 175 Lorenzo Strigini is Professor of Systems Engineering in the Centre for Software Reliability at City University, London, which he joined in 1995. In 1985-1995 he was a researcher with the Institute for Information Processing of the National Research Council of Italy (IEI-CNR), Pisa, Italy, and spent several periods as a research visitor with the Computer Science Department at the University of California, Los Angeles, and the Bell Communication Research laboratories in Morristown, New Jersey.
    [Show full text]
  • Design by Contract: the Lessons of Ariane
    . Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] several hours (at least in earlier versions of Ariane), it was better to let the computa- tion proceed than to stop it and then have Design by to restart it if liftoff was delayed. So the SRI computation continues for 50 seconds after the start of flight mode—well into the flight period. After takeoff, of course, this com- Contract: putation is useless. In the Ariane 5 flight, Object Technology however, it caused an exception, which was not caught and—boom. The exception was due to a floating- point error during a conversion from a 64- The Lessons bit floating-point value, representing the flight’s “horizontal bias,” to a 16-bit signed integer: In other words, the value that was converted was greater than what of Ariane can be represented as a 16-bit signed inte- ger. There was no explicit exception han- dler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the onboard computers, hence the mission. This is the kind of trivial error that we Jean-Marc Jézéquel, IRISA/CNRS are all familiar with (raise your hand if you Bertrand Meyer, EiffelSoft have never done anything of this sort), although fortunately the consequences are usually less expensive. How in the world everal contributions to this made up of respected experts from major department have emphasized the European countries, which produced a How in the world could importance of design by contract report in hardly more than a month.
    [Show full text]
  • Improving Software Reliability Using Software Engineering Approach- a Review
    International Journal of Computer Applications (0975 – 8887) Volume 10– No.5, November 2010 Improving Software Reliability using Software Engineering Approach- A Review Aasia Quyoum Mehraj – Ud - Din Dar S. M. K. Quadri Research Scholar Director, IT & SS Director Computer Sciences University of Kashmir (India) University of Kashmir (India) University of Kashmir (India) ABSTRACT Randomness means that the failure can‟t be predicted accurately. Software Reliability is an important facet of software quality. The randomness of the failure occurrence is necessary for Software reliability is the probability of the failure free operation reliability modeling. In [MIO87], it is suggested that reliability of a computer program for a specified period of time in a specified modeling should be applied to systems larger than 5000 LOC. environment. Software Reliability is dynamic and stochastic. It differs from the hardware reliability in that it reflects design 3. RELIABILITY PROCESS perfection, rather than manufacturing perfection. This article The reliability process in generic terms is a model of the provides an overview of Software Reliability which can be reliability-oriented aspects of software development, operations categorized into: modeling, measurement and improvement, and and maintenance. The set of life cycle activities and artifacts, then examines different modeling technique and metrics for together with their attributes and interrelationships that are software reliability, however, there is no single model that is related to reliability comprise the reliability process. The artifacts universal to all the situations. The article will also provide an of the software life cycle include documents, reports, manuals, overview of improving software reliability and then provides plans, code configuration data and test data.
    [Show full text]
  • Theoretically Comparing Design Thinking to Design Methods for Large- Scale Infrastructure Systems
    The Fifth International Conference on Design Creativity (ICDC2018) Bath, UK, January 31st – February 2nd 2018 THEORETICALLY COMPARING DESIGN THINKING TO DESIGN METHODS FOR LARGE- SCALE INFRASTRUCTURE SYSTEMS M.A. Guerra1 and T. Shealy1 1Civil Engineering, Virginia Tech, Blacksburg, USA Abstract: Design of new and re-design of existing infrastructure systems will require creative ways of thinking in order to meet increasingly high demand for services. Both the theory and practice of design thinking helps to exploit opposing ideas for creativity, and also provides an approach to balance stakeholder needs, technical feasibility, and resource constraints. This study compares the intent and function of five current design strategies for infrastructure with the theory and practice of design thinking. The evidence suggests the function and purpose of the later phases of design thinking, prototyping and testing, are missing from current design strategies for infrastructure. This is a critical oversight in design because designers gain much needed information about the performance of the system amid user behaviour. Those who design infrastructure need to explore new ways to incorporate feedback mechanisms gained from prototyping and testing. The use of physical prototypes for infrastructure may not be feasible due to scale and complexity. Future research should explore the use of prototyping and testing, in particular, how virtual prototypes could substitute the experience of real world installments and how this influences design cognition among designers and stakeholders. Keywords: Design thinking, design of infrastructure systems 1. Introduction Infrastructure systems account for the vast majority of energy use and associated carbon emissions in the United States (US EPA, 2014).
    [Show full text]
  • Combining Design by Contract and Inference Rules of Programming Logic Towards Software Reliability
    Combining Design by Contract and Inference Rules of Programming Logic towards Software Reliability Nuha Aldausari*, Cui Zhang and Jun Dai Department of Computer Science, California State University, Sacramento, CA 95819, U.S.A. Keywords: Software Security, Software Reliability, Program Specifications, Error Detection, Design by Contract, Programming Logic. Abstract: Detecting errors in software products is very important to software reliability because many security vulnerabilities are caused by the defects in software. Design by contract (DBC) is an effective methodology that dynamically checks whether a program meets its specifications, which are also called design contracts, and whether there are errors in the program. The contracts for object-oriented programs are defined in terms of preconditions and postconditions for methods as well as invariants for classes. However, if there is an error in a large piece of code that has a design contract, it is still difficult to identify the exact location of that error. To address this issue, a tool named Subcontractor has been developed. Subcontractor is implemented in Eclipse environment using libraries such as Java Development Tools (JDT), Plugin Development Environment (PDE), and JFace. The tool Subcontractor is built upon an open source DBC tool, OpenJML Runtime Assertion Checking (RAC), which is a tool that verifies specifications at runtime. Subcontractor combines this DBC tool with inference rules of program logic for if-statements and loop- statements to automatically generate subcontracts for programs. When the programs, with subcontracts automatically generated and inserted by Subcontractor, are verified using OpenJML Runtime Assertion Checking (RAC), identification of errors in the code can be facilitated. 1 INTRODUCTION (University of Oldenburg, 2001), and Contracts for Java (C4J) (Bergström, 2012).
    [Show full text]
  • 3. Design by Contract
    3. Design by Contract Oscar Nierstrasz Design by Contract Bertrand Meyer, Touch of Class — Learning to Program Well with Objects and Contracts, Springer, 2009. 2 Bertrand Meyer is a French computer scientist who was a Professor at ETH Zürich (successor of Niklaus Wirth) from 2001-2015. He is best known as the inventor of “Design by Contract”, and as the designer of the Eiffel programming language, which provides built-in for DbC. DbC was first described in a technical report by Meyer in 1986: https://en.wikipedia.org/wiki/Design_by_contract Who’s to blame? The components fit but the system does not work. Who’s to blame? The component developer or the system integrator? 3 DbC makes clear the “contract” between a supplier (an object or “component”) and its client. When something goes wrong, the contract states whose fault it is. This simplifies both design and debugging. Why DbC? > Design by Contract —documents assumptions (what do objects expect?) —simplifies code (no special actions for failure) —aids debugging (identifies who’s to blame) 4 As we shall see, DbC improves your OO design in several ways. First, contracts make explicit the assumptions under which an object (supplier) will work correctly. Second, they simplify your code, since no special action is required when things go wrong — the exception handling framework provides the necessary tools. Third, contracts help in debugging since errors are caught earlier, when contracts are violated, not when your program crashes because of an invalid state, and it is clear where to lay the blame for the violation (i.e., in the object or its client).
    [Show full text]
  • VTE Framework: Fashion Technology
    Massachusetts Department of Elementary & Secondary Education Office for Career/Vocational Technical Education Vocational Technical Education Framework Business & Consumer Services Occupational Cluster Fashion Technology (VFASH) CIP Code 500407 June 2014 Massachusetts Department of Elementary and Secondary Education Office for Career/Vocational Technical Education 75 Pleasant Street, Malden, MA 02148-4906 781-338-3910 www.doe.mass.edu/cte/ This document was prepared by the Massachusetts Department of Elementary and Secondary Education Mitchell D. Chester, Ed.D. Commissioner Board of Elementary and Secondary Education Members Ms. Maura Banta, Chair, Melrose Ms. Harneen Chernow, Vice Chair, Jamaica Plain Mr. Daniel Brogan, Chair, Student Advisory Council, Dennis Dr. Vanessa Calderón-Rosado, Milton Ms. Karen Daniels, Milton Ms. Ruth Kaplan, Brookline Dr. Matthew Malone, Secretary of Education, Roslindale Mr. James O’S., Morton, Springfield Dr. Pendred E. Noyce, Weston Mr. David Roach, Sutton Mitchell D. Chester, Ed.D., Commissioner and Secretary to the Board The Massachusetts Department of Elementary and Secondary Education, an affirmative action employer, is committed to ensuring that all of its programs and facilities are accessible to all members of the public. We do not discriminate on the basis of age, color, disability, national origin, race, religion, sex, gender identity, or sexual orientation. Inquiries regarding the Department’s compliance with Title IX and other civil rights laws may be directed to the Human Resources Director, 75 Pleasant St., Malden, MA 02148-4906. Phone: 781-338-6105. © 2014 Massachusetts Department of Elementary and Secondary Education Permission is hereby granted to copy any or all parts of this document for non-commercial educational purposes.
    [Show full text]
  • ADAS and Autonomous Driving Validation V&V
    Siemens-Microsoft Enabling simulation at scale Unrestricted ADAS/AD V&V framework 1. Context and challenges 2. Siemens ADAS/AD V&V framework a) Overview b) Environment and sensor simulation c) Vehicle dynamics and powertrain d) Simulation orchestration 3. Wrap-up and next steps Unrestricted © Siemens AG 2019 Page 2 Siemens PLM Software ADAS/AD V&V framework 1. Context and challenges 2. Siemens ADAS/AD V&V framework a) Overview b) Environment and sensor simulation c) Vehicle dynamics and powertrain d) Simulation orchestration 3. Wrap-up and next steps Unrestricted © Siemens AG 2019 Page 3 Siemens PLM Software Disruptive Innovation Key to sustained business Connectivity Autonomous Vehicles Vehicle Electrification Smart Mobility Engineering the NEXT product not just the best product for the future Unrestricted © Siemens AG 2019 Page 4 Siemens PLM Software Addressing engineering challenges for autonomous driving FROM ADAS TO AUTONOMOUS DRIVING… “+25% CAGR (through 2030) for Sensors” Roland Berger , on “Autonomous Driving”, 2014 Driver role ““…14.2 billion kilometers (8.8 billion miles) of Vehicle role testing, including simulation, are required.” SAE Akio Toyoda, CEO of Toyota Level 0 1 2 3 4 5 Paris Auto Show 2016 No Driver Partial Conditional High Full Automation assistance automation automation automation automation “Design validation will be a major – if not the largest – cost component” Roland Berger “Autonomous Driving” 2014 “While hardware innovations will deliver - software will remain a critical bottleneck” McKinsey Unrestricted“When will ©the Siemens robots AG hit 2019the road?” Page 5 Siemens PLM Software ADAS/AD systems virtual V&V Automotive industry needs Virtual validation • The number of scenarios needed to (MiL, SiL) properly validate ADAS/AD systems will explode from SAE level 1 up to level 5.
    [Show full text]
  • Breaking Down Silos with Contract Based
    Breaking down silos with contract based design for industrial software development: illustrated through an aerospace case study Vijay Singh, Tuur Benoit, Vincent Braibant To cite this version: Vijay Singh, Tuur Benoit, Vincent Braibant. Breaking down silos with contract based design for industrial software development: illustrated through an aerospace case study. ERTS 2018, Jan 2018, Toulouse, France. hal-02156100 HAL Id: hal-02156100 https://hal.archives-ouvertes.fr/hal-02156100 Submitted on 14 Jun 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Breaking down silos with contract based design for industrial software development: illustrated through an aerospace case study Vijay B. Singh, Tuur Benoit, Vincent Braibant Simulation and Test Solutions, Siemens Digital Factory, Product Lifecycle Management Abstract Contract based approaches have been studied for quite some time but adoption by the mainstream embedded software community and establishing a proper industrial process and methodology has shown to be slow and mainly limited to the architecture team and is not extended to rest of the software teams. This paper presents an integrated development environment for contract based development of embedded systems that addresses a number of challenges in adopting formal methods and contract based approaches.
    [Show full text]