{"id":2624,"date":"2019-11-20T08:00:00","date_gmt":"2019-11-20T13:00:00","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/?p=2624"},"modified":"2026-03-26T12:06:20","modified_gmt":"2026-03-26T16:06:20","slug":"application-development-and-quality-assurance","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/application-development-and-quality-assurance\/","title":{"rendered":"Application Development and Quality Assurance"},"content":{"rendered":"\n
This is part six 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

Large-scale trends\nin the automotive industry are making embedded software development more\nfundamental to vehicle development overall. Vehicle electrification,\nconnectivity, automation, and shared mobility are driving a need for remarkably\nsophisticated software to enable features like advanced driver assistance\nsystems (ADAS), battery management, vehicle-to-everything (V2X) communication,\nand more. <\/p>\n\n\n\n

In part six, we will continue in the automotive embedded application development process to look at application development and quality assurance (figure 1). <\/p>\n\n\n\n

\"\"
Figure 1: Application development and quality assurance includes architecture and model development, code implementation and verification, and quality assurance and compliance certification. <\/figcaption><\/figure><\/div>\n\n\n\n

Software engineers are\nalready deeply involved in the development process as they start to evaluate\nsoftware architectures and construct software models to prove out the\nfunctionality required by the system level definition. Many OEMs and suppliers have\nadopted a model-driven software development approach for their application\ndevelopment. The architecting and modeling processes are intended to verify and\nvalidate the software\u2019s functionality before any code is written or modified. <\/p>\n\n\n\n

As models are constructed\nand evaluated, software engineering teams begin sprints assigning coding tasks\nto implement the models. It is imperative that software engineers ensure\nconsistent modeling practices across the software-component architecture.\nConsistent models ensure that teams can perform accurate trade-off analyses to\noptimize the architecture for the vehicle or platform-level needs. <\/p>\n\n\n\n

Process Inconsistencies<\/h3>\n\n\n\n

OEMs\nusually use vehicle milestones to track system-level vehicle features, changes,\nand updates. Meanwhile, software development is accomplished through fast-paced\nAGILE and hybrid AGILE flows. The discrepancy between these development\nmethodologies can create checkpoint issues that hinder progress. <\/p>\n\n\n\n

Additionally,\nconflicting development methodologies complicate the tracing and visibility of\ninformation between teams. During testing, especially hardware-in-the-loop\n(HiL) or driver-in-the-loop (DiL) testing, it is critical that software teams know\nwhat they are testing for, and, more importantly, the reasons for the tests.\nThis includes knowing what changes have been made to which data artifacts, what\ntrigged the change (requirements, specifications, risks mitigations, etc.), which\nsoftware builds to use, and which hardware abstraction levels are required for\nspecific test methods. In the other direction, the teams responsible for\nimplementation need visibility to testing results so they can make updates and\nresolve issues uncovered in testing.<\/p>\n\n\n\n

Application Development\n& QA with a Unified Platform for Application Development<\/h3>\n\n\n\n

Fortunately, solutions are available today that help track and manage the complex and concurrent tasks involved in the application development and quality assurance<\/a> process. When it comes to task management, these modern solutions can be configured to automatically assign new work items to team members based on a set of conditions specified on a project basis. <\/p>\n\n\n\n

These\nsolutions also include iterative planning tools that can\nprovide estimations for task completion based on empirical data. Team leaders\nor application owners can define the conditions for a completed workflow, e.g.\na workflow will only be marked complete if documentation is submitted. Users\ncan also attach supportive documentation, such as component and design\nrequirement specifications, to\nensure functional and quality consistency.<\/p>\n\n\n\n

Accountability\nfor the performance of development tasks and change implementation is also\nassured. Teams can ensure that a software release or build has all of the planned\nupdates, with full traceability for each source code modification to the\nrelevant change request.\u200b<\/p>\n\n\n\n

Quality assurance and compliance certification is typically a\ncontinuous process throughout development. Test cases, test plans, and test vectors\nfor both virtual and physical testing are defined while requirements,\narchitectures, and application code are developed and matured. With a\nunified platform for application development and orchestration, testing is\ndriven directly from the requirements to ensure the quality of delivered\napplication binary and associated files. Requirements-driven testing can also\nbegin earlier in development to prevent costly late-stage defects.<\/p>\n\n\n\n

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

In part five, we introduced the example of implementing a system-level change that combines the automatic emergency braking (AEB) and adaptive cruise control (ACC) features on the adaptive cruise control module (ACCM). The process continues as software architects, developers, and test engineers execute and verify code level changes (figure 2).<\/p>\n\n\n\n

\"\"
Figure 2: Application development tasks required to implement a combined AEB and AEC feature. <\/figcaption><\/figure><\/div>\n\n\n\n

The changes made to the software architecture in Embedded Software\nDesigner (ESD), or an equivalent solution, prompt a sprint to change the\nsoftware code. Progress on the sprint is traced all the way back to the\nengineering change notice (ECN) in the PLM solution, and to the system level\nvehicle milestones tracking the readiness of the combined AEB and ACC feature.\nThe software architect can also assign code level changes with C-shell exports\ndescribing the new functional implementation.<\/p>\n\n\n\n

The software developer uses the\nupdated software architecture to identify code changes that need to be made.\nBefore the developer implements the changes, they can verify them against the\nsystem level definition through links between the application development\nplatform and System Modelling Workbench (SMW). This connection enables the\nsoftware developer to understand the system implication before committing\nchanges to the code.<\/p>\n\n\n\n

The software test engineer is prompted\nto conduct software-in-the-loop (SiL) testing by the application engineering\nplatform once the code changes are committed. The test engineer will be served\nall the relevant requirements an test cases with this notification. When the\nSiL test results come back positive, the platform triggers a\nhardware-in-the-loop test (HiL) on an emulated ECU. The HiL test flags an issue\ndue to a failed input parameter on the CAN signal caused by a delay in the CAN\nsignal timing. The issue is resolved with an update to the CAN signal sampling\ninterval. The application engineering platform tracks the discovery and\nresolution of this issue to demonstrate the quality of the delivered\napplication.<\/p>\n\n\n\n

The embedded application engineering\nplatform supports the use of AGILE processes for updating software code despite\nthe use of milestone-based development at the product level. As developers\nengage in sprints, the application engineering platform ensures that changes\nare made in the context of system level constraints. The platform also ensures\nthat the software test engineers know exactly what  to test and why they are performing the tests.\nFacilitating SiL and HiL tests enables the engineers to  catch issues early in development, reducing\nthe cost required for resolution. <\/p>\n\n\n\n

Conclusion<\/h3>\n\n\n\n

The software component architecture\nand modelling tasks verify and validate that component interactions achieve the\ndesired functionality. As models become more robust and complete with\nverification and validation, code changes and updates can be completed and\ntested with software-in-the-loop (SiL) testing. Engineers can then perform\nmodeling level updates and test again to ensure consistency, compatibility and\noverall accountability with needed reports and audit trails. <\/p>\n\n\n\n

Working from software models not\nonly speeds up the process, but can instill methods such as SOTIF (Safety Of\nThe Intended Functionality) to ensure that the software is working as intended,\nand hazards are prevented by-design. Incorporating SOTIF methods complements\nstandard functional safety approaches that mitigate risks by employing safety\ngoals that assume faults will occur. This combination produces exceptionally\nrobust automotive embedded software applications.<\/p>\n\n\n\n

A unified software engineering platform ensures data consistency despite constant changes, keeping all the parties in the development process continuously involved in delivering quality software applications that are compatible with the full range of vehicle variability. Such a platform achieves this data coherency through robust integrations with the various tools used in application development, and powerful change management capabilities.<\/p>\n\n\n\n

You can continue reading about application development and quality assurance processes in our whitepaper<\/a>. The final part<\/a> of our blog series will discuss the delivery, monitoring, and maintenance of embedded applications. To read the previous blog on application definition and planning, click here<\/a>.<\/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 six 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":2600,"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-2624","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-SMALL-AV-software-critical-scaled.jpg","_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/posts\/2624","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=2624"}],"version-history":[{"count":5,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/posts\/2624\/revisions"}],"predecessor-version":[{"id":3655,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/posts\/2624\/revisions\/3655"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/media\/2600"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/media?parent=2624"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/categories?post=2624"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/tags?post=2624"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/industry?post=2624"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/product?post=2624"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/thought-leadership\/wp-json\/wp\/v2\/coauthors?post=2624"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}