{"id":2599,"date":"2019-11-14T18:54:31","date_gmt":"2019-11-14T23:54:31","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/?p=2599"},"modified":"2026-03-26T12:06:19","modified_gmt":"2026-03-26T16:06:19","slug":"application-definition-and-planning","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/application-definition-and-planning\/","title":{"rendered":"Application Definition and Planning"},"content":{"rendered":"\n
This is part five of a seven-part series on the growing importance of automotive software. Click here<\/a> to read part one. <\/em> You can also download our whitepaper<\/a>, or visit siemens.com\/aes<\/a> to learn more.<\/em> <\/h5>\n\n\n\n

Automotive embedded application development is an ever-changing and maze-like endeavour where many different tools and teams must try to collaborate under constantly shifting constraints. This environment makes cooperation a challenge, leading to problems. Today, software systems are a major source of program risk due to the complexity and criticality of software applications. As companies target connected, electric, and autonomous vehicles, the complexity of the vehicle software will only increase (figure 1). In fact, Jaguar Land Rover expects that self-driving vehicles will contain about one billion lines of code (Shale-Hester, 2019<\/a>).<\/p>\n\n\n\n

\"\"
Figure 1: As software becomes responsible for passenger safety, its complexity will increase significantly. <\/figcaption><\/figure>\n\n\n\n

The key to effective application development is ensuring overall consistency and compatibility between the work that various stakeholders are performing across multiple domains and organizational structures. In this blog, part five of our series on automotive embedded software development, we will focus on the application definition and planning stage. This stage stretches over the product integration, requirements, tests & targets, and the architecture definition and modelling processes.<\/p>\n\n\n\n

Application definition and planning\nis triggered as the feature or system-level requirements, specifications, and\nconstraints are cascaded to the software-component-level abstraction. These\nrequirements, specifications, and constraints convey the vehicle platform or\nvehicle level feature design intent relevant for the embedded application\ndesign.<\/p>\n\n\n\n

Software engineers decompose the system level definition\ndown to the application level refinements and trigger updates to the planning\nfor the software-component-level architecture. Typically, OEMs push for software\nfunction standardization and re-use across features and vehicle platforms so\nthat downstream software-component-level architectural considerations can be\nstreamlined. <\/p>\n\n\n\n

A major challenge is deriving the\nrequirements, specifications, and target behaviors of the application and\nsoftware functions, while maintaining a system level context. Software\nengineers must know how each element of the application definition ties back to\nthe related elements of the system level features, constraints, or requirements\nto assess change impacts, realize innovative solutions to design problems, and\nmore. Ambiguous, missing, or incomplete information is common and can cause\nlengthy delays or expensive rework downstream. This is where a unified,\nintegrated, and extensible platform for embedded application development can\ndeliver a considerable value-add.<\/p>\n\n\n\n

Coordinating Application Definition and Planning<\/h3>\n\n\n\n

Advanced application development and coordination platforms can consume and track the system level product definition to create a direct link between system level changes and application development, ensuring the application and the overall system development stay in sync (figure 2).<\/p>\n\n\n\n

\"\"
Figure 2: An embedded application development and coordination platform provides a unified digital thread throughout application development. <\/figcaption><\/figure>\n\n\n\n

As system engineers make tradeoffs\nfor new and modified content at the vehicle platform level architectures, the\nresulting changes to requirements, models, specifications, safety goals and\nmore at other abstractions must be cascaded appropriately to all affected\nstakeholders. This includes embedded software application development, which\nmay be in process at the OEM or at multiple suppliers. <\/p>\n\n\n\n

Cascading this information\nthroughout and between organizations requires the integration of tools in a way\nthat makes collaboration between systems engineers and application development\nengineers inherent to the engineering environment. This demands a platform that\nprovides full traceability all the way upstream to the system context and\ndownstream to models and lines of code. This enables the engineering teams to reduce\nthe number of deviations, non-conformance, reworks, project delays, and warrantee\nrelated recalls.<\/p>\n\n\n\n

\u200bAs the application-specific\nrequirements, specifications, and behaviors are refined, an advanced\napplication development and coordination platform will prompt software\narchitects to optimize the software architecture by creating or updating\nsoftware models and capturing interactions between software components. Such\na platform orchestrates the creation and modification of these\ndeliverables by facilitating collaboration across industry standard tools such\nas Embedded Software Designer (ESD), MATLAB\/SIMULINK, Enterprise Architect, and\nothers. <\/p>\n\n\n\n

As the models and component\ninteractions are developed and become mature, the application development and\ncoordination platform can link them back to the application definition for\nverification and validation. This ensures that all the necessary requirements,\nspecifications, and behaviors have a model representation with robust\narchitecture that connects all the necessary software component interactions. \u200bThis\nstep validates the software model before full code is committed and implemented.<\/p>\n\n\n\n

By unifying the application\ndefinition and planning stage activities with a single platform, software engineering\nteams can track tasks assigned or flagged as suspect (due to a change) for\nmodeling, coding, test-execution, build production, and more across the needed\ntoolsets. The platform allows all engineering teams to peek into the system\nlevel definitions and constraints and collaborate with other system users as\nchanges are flagged. <\/p>\n\n\n\n

Example: Implementing a System Level Change<\/h3>\n\n\n\n

For example, consider the implementation of a change from the system-level abstraction with a unified platform for application development and coordination (figure 3). The change combines the system-level automatic emergency braking (AEB) and adaptive cruise control (ACC) features on the adaptive cruise control module (ACCM).<\/p>\n\n\n\n

\"\"
Figure 3: An example change implementation flow combining the AEB and ACC features on the ACCM.<\/figcaption><\/figure>\n\n\n\n

The systems engineer\nupdates the functional interaction to combine the AEB and ACC features. This\nupdate results in a new functional allocation to the logical ACCM ECU\nconsisting of new functions. These new allocated functions have additional\nrequirements that are now available for the ACCM software application\nimplementation. An engineering change notice (ECN) is created from the system\nlevel in the PLM solution. The ECN propagates the change to the lead software\nengineer, via the embedded application engineering platform, for implementation\nin the ACCM software application. <\/p>\n\n\n\n

Having been notified\nof the change, the ACCM software leadinvestigates the functional\nchanges and reviews the added or modified functional requirements. This enables\nthe software lead to examine the effect of the change on the software\nrequirements. With this understanding, the software lead assigns the creation\nor modification of software requirements to the software engineer. <\/p>\n\n\n\n

The software\nengineer uses the application engineering platform to review the functional\nchanges required as a result of the added or modified functional requirements\nin the PLM solution. The engineer then modifies the software requirements and\nadds new ones to reflect the added functionality. The embedded application\nengineering platform provides metrics on the quality of changes to the requirements\nand creates links to flag suspected changes in modeling, coding, testing, and application\nbuilds as a result of the requirements changes. <\/p>\n\n\n\n

The software architect is able to view the suspect links to\nthe affected models or architectures on their home page of the application\nengineering platform. The architect evaluates the impact of the new\nrequirements and resolves any suspects. The architect then modifies software\narchitecture accordingly in ESD, and generates Simulink models for model-in-the-loop\n(MiL) verification. Saving the Simulink models automatically triggers an update\nin the embedded application engineering platform, maintaining traceability. <\/p>\n\n\n\n

In this example, a\nsystem level change led to software level changes, which the application\nengineering platform automatically identified to the key persona: the software\nlead. The software lead was able to view the system level changes in the\ncontext of the software implementation, making the needed changes to the\nsoftware application much clearer. As the software engineer reviews and\nimplements the needed application requirements changes, the application\nengineering platform ensures the changes are completed with clarity and quality\nwhile remaining in the context of the system level changes. The embedded\napplication development platform automatically organizes the modeling and\narchitecture data the software architect needs to implement modeling changes\nand perform needed testing.<\/p>\n\n\n\n

Application Definition and Planning: From Chaos to Coordination<\/h3>\n\n\n\n

A unified software engineering platform enables engineers to\ninteract with the product direction and system definition. This interactivity\nensures that software engineering stays consistent with the system needs and\nhardware constraints while they implement at the application level.\nFurthermore, this end-to-end traceability allows close alignment between OEM\nand supplier guidelines, activities, and timelines with clarity and quality. As\nsoftware engineers and architects complete the application definition and\nplanning, they can also leverage this platform to ensure consistency and make\ntrade-off analyses across the functional architecture. <\/p>\n\n\n\n

Application definition and planning is just the first step in developing the sophisticated software applications that are in high demand today. To read more about this initial step, please download our whitepaper Orchestrating Automotive Embedded Application Development: Application Definition and Planning<\/a>. Part six<\/a> in our series will cover application development and quality assurance, and part seven will discuss application delivery and maintenance.<\/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\n\n\n

References<\/h2>\n\n\n\n

Shale-Hester, T. (2019, April 16). Driverless cars will require one billion lines of code, says JLR. Auto Express<\/em>. Retrieved from https:\/\/www.autoexpress.co.uk\/car-news\/106617\/driverless-cars-will-require-one-billion-lines-of-code-says-jlr<\/a> <\/p>\n","protected":false},"excerpt":{"rendered":"

This is part five 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":2602,"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-2599","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-3-example-change-flow-scaled.jpg","_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/posts\/2599","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=2599"}],"version-history":[{"count":5,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/posts\/2599\/revisions"}],"predecessor-version":[{"id":3654,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/posts\/2599\/revisions\/3654"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/media\/2602"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/media?parent=2599"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/categories?post=2599"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/tags?post=2599"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/industry?post=2599"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/product?post=2599"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/coauthors?post=2599"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}