{"id":2590,"date":"2019-11-14T17:55:10","date_gmt":"2019-11-14T22:55:10","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/?p=2590"},"modified":"2026-03-26T12:06:17","modified_gmt":"2026-03-26T16:06:17","slug":"automotive-embedded-software-takes-center-stage","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/automotive-embedded-software-takes-center-stage\/","title":{"rendered":"Automotive Embedded Software Takes Center Stage"},"content":{"rendered":"\n
This is part four of a seven-part series on the growing importance of automotive software. Click here<\/a> to read part one. You can also download our whitepaper<\/a>, or visit siemens.com\/aes<\/a> to learn more.<\/em><\/h5>\n\n\n\n

Automotive embedded software has become critical to the functionality, desirability, and performance of modern vehicles. Software plays a key role in providing users with intuitive and exciting experiences while also improving vehicle efficiency, performance, and safety. Everything from navigation and infotainment systems to advanced driver assistance systems (ADAS) relies on embedded software applications.<\/p>\n\n\n\n

The broader trends of vehicle electrification, connectivity, autonomy, and shared mobility<\/a> will drive additional changes in the automotive embedded software landscape. Vehicle software features will integrate with cloud-based capabilities to enhance passenger and service-oriented features. Furthermore, electrical and electronic (E\/E) architectures are centralizing and becoming modular while software features and functionality are being standardized across OEM product lines.<\/p>\n\n\n\n

To keep up with these new technologies and organizational structures, as well as functional safety<\/a> standards such as ISO 26262, existing development processes and methodologies are rapidly evolving. In this blog, we will discuss the process evolutions that OEMs are undertaking at a high level to keep pace with a changing automotive landscape. <\/p>\n\n\n\n

Automotive embedded software development is an intricate process involving multiple domains, such as mechanical, electrical and electronics (E\/E), and software, across several organizations, including powertrain, chassis, body, E\/E, IT, research, and advanced-engineering. Each of these domains and organizations work together to develop a comprehensive set of vehicle platform features (figure 1). But, the increasing complexity of automotive embedded software places additional pressure on the ability of cross-organizational and cross-domain teams to effectively collaborate at a grass-roots level. These interactions, and the massive amount of resulting data artifacts, need to be managed across the development lifecycle. Accurate and clear engineering data must be available to the relevant teams as needed to ensure the coverage of the functional definition and the quality of information.<\/p>\n\n\n\n

\"\"
Figure 1: Automotive embedded software development is a highly complex task that involves many organizations across varying engineering domains. <\/figcaption><\/figure>\n\n\n\n

Additionally,\nsoftware and vehicle development teams operate on different cadences. OEMs\nusually use vehicle milestones to track overall system-level vehicle features,\nchanges, and updates. Meanwhile, software development is accomplished through\nfast-paced AGILE or hybrid AGILE flows. The discrepancy between these\ndevelopment methodologies can create checkpoint issues that hinder progress. For\nexample, the software teams may have to wait for system-level updates that may\nnot be ready for general consumption until the next milestone. Likewise,\nsoftware teams may be under pressure to produce a software build for the next\nmilestone, compromising quality to meet a deadline. <\/p>\n\n\n\n

The conflicting\ndevelopment methodologies between software and product teams cause additional\nchallenges. Tracing and visibility of information from application to\nsystem-level is much more difficult as software continuously grows in\ncomplexity. As hardware and software mature at different rates, assessing the\ncompleteness of software applications, and features, and their compatibility\nwith vehicle systems becomes very difficult. <\/p>\n\n\n\n

Feature-Centric Application Development<\/h3>\n\n\n\n

OEMs and suppliers realize that vehicle\nmargins are tightening due to market disruptions and tough competition. This\ntrend is placing greater attention on the engineering of vehicle features, especially\nthose that are driven by software. Software-driven features are becoming a central\ntheme of vehicle development, as these features increasingly provide the\nexciting capabilities (the \u201cwow factor\u201d) needed for vehicle differentiation.\nFurthermore, software features can be updated more frequently, improving or\nfortifying a vehicle\u2019s attractiveness in a crowded market. <\/p>\n\n\n\n

Vehicle-level software feature\nrequirements evolve at the vehicle or platform-level interactions. Embedded\nsoftware applications then realize these features by calling on an array of\nvehicle functions implemented over a number of computing units, sensors and\nactuators.<\/p>\n\n\n\n

Original equipment manufacturers\n(OEMs) typically deal with the entire vehicle-level software feature\ndevelopment. Each OEM defines features and functions a little differently, so\nthere is no hard guideline on what constitutes a feature versus a function. In\ngeneral, a vehicle level software feature is either something that the customer\ninteracts with (steering, climate-control, infotainment), or it is a high-level\nvehicle engineering needs such as torque management, battery-management, or\nother capabilities. A feature is composed of dozens of functions, while\nsoftware functions are combined to implement embedded software applications. It\nis critical that OEMs facilitate functional reuse, redundancy, and variance\nacross organizational boundaries, although this is much easier said than\ndone.   <\/p>\n\n\n\n

OEMs are vertically integrating with\nin-house teams developing their own software, while suppliers compete to deliver\ninnovation to support the required feature set. Throughout this process, OEMs\nmust manage the engineering content for each feature. This includes ensuring\nthat unique functionality is created as necessary, common or reusable\nfunctionality is leveraged, the variance of functional implementations is\ncaptured, dependencies of functional inputs and outputs are understood, and that\nthe feature compatibility with vehicle-program needs is validated. <\/p>\n\n\n\n

To complicate the implementation\nand operation of vehicle features, each application development team usually is\nresponsible only for their own functional content, and not the overall feature(s).\nAs a result, engineering organizations at both suppliers and OEMS tend to take\nan ECU (hardware) centric approach \u2013 focusing less on the feature that is being\nimplemented. <\/p>\n\n\n\n

In such approaches, it is very\nchallenging and time-consuming to continuously verify and validate (V&V)\nthe vehicle feature as various software and hardware components separately\nreach maturity. As a result, OEMs are attempting to disengage the dependence of\nfunctions to specific ECU hardware. Consequently, ECUs become computing abstractions\n(much like a cell phone) on which various software apps can be hosted. These\ncomputing abstractions can communicate over an underlying communication layer\noptimized for these computing units and cloud interactions.<\/p>\n\n\n\n

A software feature-centric, architecture-driven\napproach can help organize the chaos of automotive embedded software\ndevelopment and enable rapid innovation. This approach allows systems engineers\nto focus on defining and managing the functional decomposition of software\nfeatures and allocating, re-using, and standardizing software components to\nlogical electrical components like ECUs (or their abstractions), sensors,\nactuators, and more. As vehicle programs ramp up, existing relationships\nbetween software functions and logical electrical components will identify each\nof the electrical components that are necessary for each feature targeted for\nthe vehicle-program. Logical electrical components can then be assigned their\nphysical part-numbers, tracked within the particular vehicle program, providing\nend-to-end traceability of how the software features are engineered and used by\neach vehicle program. <\/p>\n\n\n\n

A Unified Platform for Automotive Embedded Software Development<\/h3>\n\n\n\n

Effectively implementing a feature-centric, architecture-driven approach provides a robust, secure, and widely accessible structured methodology to design, create, track and improve the complex software features that are distributed across a multitude of in-vehicle ECU abstractions, and often sourced from many suppliers across the globe. Constructing a holistic picture of the status and completeness of these many applications is critical to delivering high-quality, safe <\/a>embedded software on time. From the bottom-up perspective of embedded software application development, keeping track of the feature-level context, and overall system constraints, is an absolute necessity.<\/p>\n\n\n\n

Achieving such a methodology requires a unified platform for embedded software development to coordinate all the activities across a diverse tool-set to deliver a fully verified and validated build under hardware and system configuration constraints (figure 2). With such a platform, OEMs and suppliers can consolidate data-flows across the tool-chain eco-system and synergize to optimize process, methods, and tools integrations.<\/p>\n\n\n\n

\"\"
Figure 2: A unified platform for automotive embedded software development is needed to deliver verified and validated application builds based on hardware and system constraints. <\/figcaption><\/figure>\n\n\n\n

This unified platform, based on Polarion\u00ae, orchestrates all activities across the embedded software application definition, planning, development, quality-assurance, and delivery lifecycle. The platform can connect with varied toolsets to facilitate organic collaboration among many engineers and ensure traceability while promoting data re-use.<\/p>\n\n\n\n

To continue reading on this topic, please download our whitepaper Creating a Unified Platform for Automotive Embedded Application Development<\/a>. In parts five<\/a>, six<\/a> and seven<\/a> of this blog series, we will look at the three main sub-processes of automotive embedded application development. As we explore each of these sub-processes, we will highlight key challenges and pain-points, and discuss how a unified software development platform can help address these concerns.<\/p>\n\n\n\n

To learn how a unified application development platform can help companies meet functional safety standards, like ISO 26262<\/a>, please register for our upcoming webinar, Increase automotive functional safety with ISO 26262 compliance<\/a>. <\/p>\n\n\n\n

About the author:<\/strong> Piyush Karkare is the Director of Global Automotive Industry Solutions at Siemens Digital Industries Software. Over a 25 year career, Piyush has a proven history of improving product development & engineering processes in the electrical and in-vehicle software domains. His specialties include integrating processes, methods, and tools as well as mentoring product development teams, determining product strategy, and facilitating innovation. <\/p>\n","protected":false},"excerpt":{"rendered":"

This is part four of a seven-part series on the growing importance of automotive software. Click here to read part…<\/p>\n","protected":false},"author":18471,"featured_media":2591,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[104],"industry":[120],"product":[],"coauthors":[],"class_list":["post-2590","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news","tag-embedded-software","industry-automotive-transportation"],"featured_image_url":"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/19\/2019\/11\/Fig-1-Car-ADAS-Driver-futuristic-dashboard-Adobe-206321037-scaled.jpg","_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/posts\/2590","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/users\/18471"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/comments?post=2590"}],"version-history":[{"count":4,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/posts\/2590\/revisions"}],"predecessor-version":[{"id":3653,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/posts\/2590\/revisions\/3653"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/media\/2591"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/media?parent=2590"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/categories?post=2590"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/tags?post=2590"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/industry?post=2590"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/product?post=2590"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/coauthors?post=2590"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}