As we mark Halloween 2020 in a changing automotive industry preparing to ship model 2021-year vehicles, it’s time to look for the unmentioned monsters haunting your embedded systems development code base.

Bugs

Remember those software changes and corner case scenarios that did not make the risk vs. cost threshold for a late software change? Software bugs can take many forms − not handling a given combination of input conditions properly is a preventable one. Nobody wants to find out that a particular corner of the box is far more possible in production than expected.

Zombies

The other unmentioned monster lurking at the end of a project is lack of documentation cleanup.  It occurs for many reasons: personnel taking vacations, team members leaving or priorities changing, and then the task just ends up dropping off the table. Thus, with time, zombie code is born.

Zombie code are those pieces of “undead” software and code designs that nobody wants to change, or the change requests are in the backlog due to late discovery.  This lack of clarity when creating the product borrows from the future in your organization in production, which matters with 20-year product life cycles.  Luckily, ETAS has a tool to resolve these issues in SCODE-ANALYZER.

Adding priorities and structure to system descriptions

SCODE-ANALYZER assists and even forces engineers ranging from rookie to expert level to develop 100% scenario coverage by considering every possible combination of inputs for a given function.  Once completed, the design can auto-generate code in C, MATLAB®, or ETAS ASCET for further integration into the software development process. SCODE-ANALYZER allows faster reviews by subject matter experts and can print reports for management and cross-functional teams in an easy to digest format.

Let’s look at the difference in two potential workflows, starting with a traditional workflow:

Traditional workflow

• Design according to product requirements, functional requirements, and Design for Failure Mode and Effect Analysis (DFMEA)
• Write pseudo code or detailed implementation requirements documents
• Hand off to software engineer after a design review
• Software engineer designs to meet the implementation requirements or refines the pseudo code into a software.
• Software engineer designs a unit test and proves that the software meets the implementation requirements.
• Software is reviewed and is released to start validation
• Validation team confirms that the design meets the system level functional requirements
• Final review and delivery

This traditional workflow is a reasonable benchmark: It is a series of steps, it is linear, it has a separation of roles, and program management can schedule it. However, this workflow often ignores the reality of embedded software development projects inside a matrix organization.  Subject matter experts’ unavailability to answer questions, ambiguous competing requirements and change requests, cross-functional team requests for software to fix a hardware shortcoming late in development, gaps in the code design, and incomplete statistical information can all cause issues in production release.  This process also does not typically handle a smooth hand-off of deliverables to the in-production team. Often, team members must read everything and reverse engineer the design years after the development team members move on to their next project or role.

Let’s contrast this with the steps of a SCODE-ANALYZER workflow:

SCODE-ANALYZER workflow

• Design according to product requirements, functional requirements, and DFMEA
• Engineers use SCODE-ANALYZER to fully-design 100% coverage for all conditions
• Design is reviewed to ensure it has the proper mode and action defined for a set of conditions
• SCODE-ANALYZER auto-generates code with an automatic check to confirm the compiled code matches the design
• Software Engineer integrates auto-generated code into a larger design and creates basic unit tests
• Virtual validation team uses Virtual ECU technology to validate the SCODE-ANALYZER software design to the functional and product requirements.
• Final Review and delivery

Using the SCODE-ANALYZER tool results in a 100% complete and consistent design and mathematically proves that there are no gaps in your software, regardless of the statistical likelihood of that combination of conditions occurring.  SCODE-ANALYZER allows linking your design decisions to requirements and therefore fixes the documentation process for how the software should behave, without requiring a separate design Word document, which may fall out of sync with the code.  No gaps exist between the SCODE-ANALYZER design on paper (I.e. the model) and the code, because it is auto-generated. Additionally, SCODE-ANALYZER utilizes so-called fingerprint technology to prove that the generated code corresponds to the designed and reviewed system.

SCODE-ANALYZER detects interdependencies between functions

While SCODE-ANALYZER cannot vanquish all lurking critters in your embedded systems product development, it can plug some of the holes in which issues can sneak in to lie dormant until later in production. Utilized by your team and company, you can sleep better knowing there are fewer bumps in the night to worry about, especially in this wild year of rapid change.

Are you ready to put your zombies to rest?  If you’d like to learn more, read our earlier posts about SCODE-ANALYZER and Virtual Validation, or contact us.