Monthly Archives: August 2018

Why the Transition from Code Based Development to Model Based Development is a Necessary Paradigm Shift in Automotive

The need to shift to Model Based Development primarily stems from the inherent complexity that manual coding process brings about during the development.

And when we say complexity, it is not just the size of the code. The direct usage of the code also makes it quite difficult to maintain the function structure of the overall system software.

In manual coding, the software developer is more focused on the code rather than the function. Furthermore, large code bases are also very difficult to port to other microcontrollers, if need for hardware platform migration arises.

Electronics has been the major differentiator among the automotive OEMs across the globe, but it has also made the software codes very complex.

Here’s a little food for thought!

Imagine the time and effort that would be required if all of the code had to be written and maintained manually. Add to it the fatigue of the developers and chances of errors in the codes.

This is the just the tip of the iceberg. We will discuss more about the need for Model based development in the subsequent sections.

Delivering Futuristic Automotive Products at Reduced Time-to-Market and Costs is the Secret Sauce for Success

In the fierce race of capturing automotive market, OEMs frequently introduce new features for enhanced comfort, safety and luxury of the end-users.

The quest is to become the first to introduce a feature so that they can ‘cash in’ the new features before others get them too.

Developing these unique features however, requires designing of complex algorithms, rigorous testing and verifications. If not done efficiently, this obviously leads to increased cost and time-to-market.

Hence, the biggest challenge before software engineers while working on these complex systems is to shorten development cycles and reduce development & testing time.

With the conventional way of software development, achieving this challenge is something like expecting to stop an angry INCREDIBLE HULK by mere hands.

On a serious note, the coding methods really need a paradigm shift. And this shift is from code based development to model-driven development or model based development (MBD) methodology.

A model-based approach shifts the emphasis on the function based rather than code-based automotive software development.

This allows the software developers and the testers to find maximum possible errors in early phases of product design and development. Whereas in conventional coding, the errors are found in testing phase, when it is ideally very late and costly to go back & make necessary corrections.

What Difference does Model Based Design Approach Bring In?

To understand the difference, we will first try to briefly explain how model based approach works.

Model based development is based on V-shaped model of Software Development Lifecycle (SDLC).

The first step is usually the requirement gathering/analysis where maximum possible design issues are identified during h/w and s/w requirement analysis by introducing requirement maturation phase.

Then comes the model development, the process that sets this approach apart from manual C language coding.

MBD techniques allows user to autogenerate code from the model without any hassle.The most important point here is that testing is performed at every step. This iterative approach ensures that the bugs are identified and resolved before moving on to the next step.

We will dig a little deeper now!

Once the initial segment of code has been shown to work successfully, the process can be extended to a system-level simulation by incorporating the code into the rest of the application.

With a system-level simulation, it is possible to perform system integration virtually and get an early perspective of how the hardware and embedded software will behave.

This is especially valuable if the hardware is still in development phase and it is expensive to create prototypes.

Once the initial model-based development trial is successfully completed, the models can be extended to other areas of the project.

Even without a full-scale model of the environment or algorithm, simulation allows tests to be conducted under various extreme operating conditions.

Based on these tests, basic parameters can be derived for inclusion into the hardware design activity. Moreover, these models can be stored for later use to solve different design problems in future development projects.

The block diagram shows the model based approach in action:

Diagram depicting the stages in model based development paradigm

The Model Based Design Approach and its Striking Benefits

Most importantly, the MBD workflow saves time and money, while improving the reliability and adaptability of the end product.

This enables organizations to introduce new features in a shorter period of time without compromising on the quality.

With Model based development:

• High-quality code can be created without manual coding
• The code can be created that matches the behavior of the model
• A model can be simulated to weed out the bugs in the algorithm
• Rapid control prototyping can be done skipping the software-in-loop (SIL) and hardware in loop (HIL) testing
• Apart from model development, using MATLAB and Simulink tools, memory optimization is also taken care of

Model-based design facilitates effective testing of the functionality, identification of defects, and verification of software performance despite constrained development schedules and budgets.

This is only possible because all external interactions and internal operations of an embedded system are represented using a model in this method of product development.

Model-Based Design allows you to improve efficiency by:

• Using a common design environment across project teams
• Linking designs directly to the requirements
• Integrating testing with design to continuously identify and correct errors
• Refining algorithms through multi-domain simulation
• Automated generation of embedded software code
• Development and reuse of test suites
• Generation of documentation
• Reuse of designs to deploy systems across multiple processors and hardware targets

Did You Know?

Software bugs cost a lot (e.g. 1200$ per line of code due to recall of cars after an unintended acceleration problem)

A model-based approach (model + code-generation) is 30% faster and has 50% less errors than manual code written by a top programmer.

Downsides of MBD

Model Based Development also comes with its own costs. Training of the engineering team on process & tools incur high cost.

However, over the long run, such costs nullify the delay and overheads that may occur using conventional approach.

Conclusion

Model-based development of complex systems in the automotive domain is being widely adopted by the main players in the automotive industry.

As of now 16% of the SLOC (no. of lines of codes) in a car are generated from models. This number is showing rapid increase as OEMs are racing against one another to introduce new features.

In the blog, we have tried to give you a high-level overview of model based development of automotive software. In the coming blogs, we will explore the inner workings of MBD in finer details. Keep reading!

8 IoT Design Mistakes You Should Avoid for a Successful IoT Solution Development Project

According to industry experts, the global internet of things (IoT) market is expected to reach USD 724.2 Billion by 2023. This has led to an overwhelming demand for IoT-ification or rather IoT  enablement of the businesses.

But at the same time, a great number of IoT projects do not result in desired outcomes, even after investing a great deal of time and money .

These failures generally occur due to crucial solution design mistakes,  that can derail the success of your IoT Implementation.

Wondering what are they? With the help of our IoT consultants, we have put together a list of must-avoid IoT system design mistakes.

Not Making ‘System Security’ Part of the Solution at Design Stage

As an IoT product development team, you should not take the risk of not integrating the security aspect at the design phase. Because it is very challenging to integrate security best practices with the IoT application/product during the deployment stage. This often results in below-par quality and robustness of the IoT application.

IoT networks are highly vulnerable and any loop-hole in security can result in loss of critical industrial data.

What makes the security of an IoT system robust? Answer lies in system integrity and verified/authentic access control of the IoT devices.

One should clearly define the data routing protocols for secure data exchange, data encryption mechanisms, data authentication and access control features.



Security Issues in IoT. Image Source: Trend Micro

Operating Environment of the IoT Devices

While designing an IoT solution, one needs to be well aware of the operating environmental conditions   where the IoT devices will be deployed (open fields, industrial assembly lines etc.).

Information about the fluctuations in temperature and moisture levels, ambient heat will help the design team to identify the required product casing type and quality grade.

This will help you in taking adequate precautions at the IoT design stage itself to pre-empt any device damage due to a bad weather or over heating conditions.

Imagine that you are designing an IoT solution for remotely managing the solar trackers in the field.  You have designed the solution as per the best practices related to all the hardware and software aspects. But you missed the ambient environment factor. In this case, if the solar tracker that is being deployed in a site which receives heavy rainfall or strong wind, the system may get damaged.

Additionally, the design considerations of your IoT solution should also be able to handle the scenarios of power failure, primary communication failure with necessary fail-over strategies in-built in the design

Flexibility in Software Codes takes the Backstage

An ideal practice while writing software code for any application, especially if it involves data centric systems like IoT, is to make it as flexible and adaptable as possible. This will ensure that the IoT application is able to support any changes in hardware or a peripheral device without extensive rewriting of the software codes.

To ensure adaptability of the software code to the changing needs of the customer, a modular software architecture should be designed. This means in order to effect certain changes, you would not have to rewrite the entire software code, but only the module that is directly connected to the component that needs to be changed/modified.

Yet another thing to be borne in mind is the power efficiency of the software code. This has an impact on the longevity of the devices in the IoT network.

This is because power inefficient IoT devices can become victim of the below-par longevity.

Lack of Data Fidelity within the IoT System

In IoT systems, data reliability plays a very important role. An efficient IoT system involves error-free, reliable data communication at all levels- namely, the devices, the gateway, the cloud server and the user interface.

When we say reliable data communication, it involves data fidelity and integrity throughout the IoT network.
Data fidelity means data from sensor to the gateway matches with the data transferred gateway to the cloud server. Verifying the data fidelity helps in determining whether the data has been altered during transmission across the IoT network & this is done at the software development level.

End-to-end data fidelity can be ensured through data acknowledgment techniques such as cyclic redundancy check (CRC) at each reception point.

Also, your IoT system should have an efficient data backup & recovery plan in the event of a software or network failure.

Ignoring the Longevity of Hardware Components

When you design the hardware you should check the validity and longevity of each and every component being used for the design. It should not happen that by the time your IoT application is ready to be deployed; the microchip that you have sourced from a particular brand has gone obsolete or is no longer available in the market. Such a situation can halt your entire project.

So, at the design stage itself you should ensure that hardware components , that are part of the IoT solution, are available in the market for a long period ( say, 5 to 6 years atleast) and has guaranteed aftermarket support and maintenance service from the manufacturers.

Inadequate IoT Testing Practices

Testing plays a major role in ensuring a reliable operation of the IoT devices.

You should have a comprehensive test plan ready for your mission critical IoT system. And IoT testing must be done at different levels- the data , the hardware, the  peripherals, the software, the network, the firmware, the user interface- to ensure that the product will work.

Typically, a highly information intensive system like IoT, which stores and processes large volumes of data and has to sync-up with large number of devices, would require extensive testing mechanisms such as regression testing, endurance testing, functional testing and unit testing.

Additionally, you should perform, vibration test, drop test, pressure test- mandatory to ensure that your field deployed IoT devices are working efficiently.

Checking the Regulatory Requirements & Certifications at the 11th Hour

Before proceeding to the production, you must ensure that your IoT application, including the various ( software & hardware) components involved in  developing it, is compliant and certified  with regulatory requirements.

Standard certifications include – CE, UL (Underwriters Laboratories), FCC, CSA (Canadian Standards Association), ROHS (Restriction of Hazardous Substances) and the likes.

Certifications	Relevance	Symbol
CE Certification	The CE marking signifies conformity with health, safety, and environmental protection standards for products manufactured in, or designed to be sold within the European Economic Area (EEA).
UL (Underwriters Laboratories) Listing Mark	The UL mark is a certification to ensure the electrical safety of a particular product or component (Electrical and Electronic Products, Industrial Control Equipment, Wires and Cable etc. )
FCC( Federal Communications Commission) Mark	The FCC label  is mandatory for  electronic products manufactured or sold in the United States  and certifies that the electromagnetic interference from the device is under limits.
CSA (Canadian Standards Association) Certificate	The CSA certification is necessary for all electrical and electronics products to be sold or installed in Canada. The CSA standards certifies a product against fire hazard, mechanical hazard, and shock or energy hazard.
ROHS (Restriction of Hazardous Substances) Directive	The RoHS directive puts restriction on use of certain hazardous substances in electrical and electronic equipment. Any RoHS compliant product is tested for the presence of Lead , Cadmium, Mercury, Hexavalent chromium , Polybrominated biphenyls, and Polybrominated diphenyl ethers.

 

At the design stage , you can plan your certification process & timelines. Wherever possible go for pre-certified components so that you can save on cost and time on procuring the certificate at the last moment.

Compromising on the Quality to Save Cost

In a bid to trim down the bottom line costs, you might be tempted to make few design compromises which could end up in sacrificing the quality of your IoT application. This is a must-avoid in order to build a quality IoT product.

Quality management and cost savings can and in fact should go hand in hand.  What you save at the design stage might have to be spent on post-deployment troubleshooting and bug fixing activities.

At the design stage itself, you can chalk out an effective plan to develop a high grade application using efficient design components (hardware & software) at an optimal cost. Your design plan must distinguish between design components with high returns and are deemed necessary, from low priority components for which low-cost alternatives are available in the market.

Hope this blog was a good read for you and offered you some food for thought on important design considerations necessary to be taken care of, before plunging into a full-fledged deployment. Would you like to learn more about the IoT implementation? Contact us.

Why ‘Safety Plan’ is Critical in Development of ISO 26262 Complaint Product and Automotive Functional Safety

Everyone who has been a part of an automotive project ideation and product development understands how critical project planning is.

Based on experiences in software development projects, a product development team may opt for various different approaches of SDLC.

One of such proven approaches is Plan-Do-Check-Act, a general practice followed during project planning, especially in compliance verification scenario.

• PLAN– Development Interface Agreement, Safety Plans
• DO– Concept documents, analysis documents, software codes
• CHECK– any form of validation like MISRA C and other audits,
• ACT– on preventive actions based on the derivations from Check stage.

With ISO 26262 coming into the picture, one more dimension called safety planning has become a critical part of such project management planning (PLAN-Do-Check-Act). ISO 26262 mandates that the organization that wishes to implement functional safety in automotive software development, needs to follow a well-defined safety culture.

In order to implement this safety culture during the safety lifecycle of the automotive software, some safety activities have to be planned and executed.

The importance of the safety planning can be gauged from the fact that the entire Part 2 of the ISO 26262 guidelines document has been dedicated to the functional safety management and the Aspects that Need to go into the Safety Plan Document.

Let’s dig deeper!

What Goes into ISO 26262 Recommended Functional Safety Plan Creation and Execution?

Safety planning management is concerned with the execution as well as the documentation of each and every safety related activity. We will discuss these activities in detail and see how are they executed and documented.

Organization Structure in Functional Safety Planning

Achieving functional safety in the automotive software development needs all the stakeholders to work towards this common goal. The interaction among the project team members needs to be defined in the safety planning activity sheet.

Aspects such as role definition, who interacts with whom, who escalates to whom etc. are required to be mentioned clearly in this section of the safety planning activity sheet.

• Project Roles & Responsibilities

  
  Part 2- Section 6 of ISO 26262 documents recommends that a project manager should be appointed at the initiation of a functional safety project, that has the mandate of achieving specific safety goals (as per the ASIL definitions).

  In addition to the project manager, a safety manager also needs to be appointed who will be responsible for following activities related to safety planning and coordination:

  • Delegation of task based on skill set, competence, and qualification
  • Maintenance of the safety plan throughout the safety lifecycle
  • Monitoring the progress of all the automotive functional safety activities

   

• Project Resources at Work

  
  In addition to the human resources that we discussed in the above section, software tools, databases, templates etc. are also required to achieve functional safety goals.

  The organization has to provide all such resources and it is the role of the safety manager to ensure that human resource gets access to them.

Project Safety Lifecycle as Recommended by ISO 26262

ISO 26262 document provides a product lifecycle diagram that needs to be referred to while creating the safety plan. One may not use the full diagram in every project as each project may have different scope.

For instance, concept development and hardware design may not be the part of the project. Hence, we need to mark those areas that come under the scope of the particular project.

• Safety case Creation

  
  In the process of developing fail-safe automotive Electric and Electronic (E&E) systems, it is necessary to provide an evidence-backed assurance. This assurance comes from the output of the safety lifecycle that is derived from the work products (documents, design and analysis artefacts) prepared during the lifecycle.

  Safety case is the argument that provides the assurance that safety requirements for a system have been implemented at the vehicle level (called an item in ISO 26262 terminology). This argument is not just a simple derivation from the work products. It is in fact, a justification of why and how the available pieces of evidence have achieved the desired level of functional safety (ASIL).

• Work Products Creation

  
  During the course of ISO 26262 recommended safety planning, several documents are created at different stages of safety lifecycle. Organization specific rules and processes, safety plan, safety case, functional safety assessment plan and confirmation measure reports are some of the work products that are generated during the safety planning process.

  These work products act like evidences that are required to substantiate that safety planning, for the automotive product development, has been performed according to the guidelines laid down by ISO 26262.

Development Interface Agreement (DIA)

DIA is an elaborate sheet that depicts all the work products for the service provider, OEM and the vendor. It is easy to understand it by considering three entities as the stakeholders of the project, as mentioned before- OEM, Vendor and Service provider.

The table will have all the work products that need to be created. The entity that is responsible for it will be marked as ‘R’. The one who will support it will be marked as ‘S’. The entity that needs to be informed about a particular work product will be marked as ‘I’ and finally the approving entity will be marked as ‘A’.

The Table below will make the interface agreement more clear to understand:



 

As there is an interfacing done between the entities in the course of development, the table is named- Development Interface Agreement (DIA).

Development Interface Agreement is a part of safety plan activity. From the documentation point of view, DIA can be kept separate or together with safety plan doc.

• Planned Safety Activities


It is a breakdown of all the activities to be done in the project. This table will cover all the required parts of the ISO 26262- from development activity of the functional requirement to the safety requirements. Any kind of additional reports and analysis that needs to be created in sync with safety requirements will also be listed here.

Development activities sheet and safety activity sheet can be combined or can be kept separate. However, from the activity perspective, both of them will be carried out simultaneously.

Automotive Functional Safety Techniques and Measures to Achieve Applicable ASIL

The analysis of software and hardware required in the project needs due diligence. If you look at part 6 of the ISO 26262 documents, several tables are provided that shows the methods and techniques for hardware and software analysis. The method to be chosen for this analysis is also decided based according to these tables. The following is one such table.


 

While doing safety planning management, the designated user will include the methods and techniques that have been chosen for the projects. Talking specifically, these methods will depend on the topic to be covered, for eg. modeling and coding guidelines.

The ISO 26262 guideline suggests that which method needs to be implemented for the desired ASIL The procedure to achieve the ASIL also has to be mentioned in its separate column. If for some reason, some methods are skipped, the justification also needs to be given as remarks.

The table below will make things clear:

• Confirmation Measures/Review is another table that is an integral part of safety planning. Again, it can be a part of DIA or be kept separate. Different service providers follow different approach which entirely depends on their understanding and requirement.

This section is essentially for the review of various work products like test cases, HARA, FIT/Gap analysis, FME (Failure Mode & Effects) Analysis, safety plan, qualification of the components etc. The confirmation can be done by the service providers themselves, certifying agencies or the consultants.

ISO 26262 Mandated Safety Audits & Assessments

The frequency of audits by internal safety assessment team can be decided by the safety manager or the project manager. The assessment can be done by internal teams but audit is usually carried out by external agencies, especially when certification is required.

The Final Thoughts

Functional Safety compliance is different from other QAs like CMMI etc. It deals with very specific functional area and requires certain skills and qualifications. Moreover, achieving functional safety in automotive software development is evidence based. These are some of the reasons why safety planning becomes a crucial part of ISO 26262 compliance.

The blog touches upon all major aspects of safety planning management as recommended by Part-2 of ISO 26262 guideline. Look for this space for more such informative blogs on ISO 26262 and Functional Safety.