×

Happy to Help!

This website doesn't store cookies. Enjoy the experience, without worrying about your data!

Great, thanks!

Monthly Archives: September 2019

  • 0

How is Software Verification Performed As Per the ISO 26262 Standard

Category : Embedded Blog

The Pre-lude:

The Part-6 of ISO 26262 standard enlists the guidelines for product development at the software level. It also has a clear and specific take on software verification and validation process.

In addition to the part-6, the Part-8 of the ISO 26262 Standard also has a separate clause that talks about the software verification in general.

When a verification strategy is planned for the ISO 26262 complaint software, recommendations from both the parts are considered.

After completing the process of HARA (Hardware and Risk Analysis), your Functional Safety (FuSa) Consultants are armed with the following necessary information:

  • The safety goals,
  • Functional Safety (FuSa) concept document
  • ASIL value.

With all this information under the sleeves, the stage gets set to kick-start the ISO 26262 compliant software development process!

Shifting Gears: Understanding the Omnipresence of Software Verification in the V-Cycle

In the V-Cycle model for software development, software verification is performed at every stage of development.

If you look at the V-model, you can find that the arrows connecting the two hands of V-model are bi-directional.

Unit testing corresponds to the software implementation, Integration test is done against the High Level Design and so on.

This is done to achieve bi-directional traceability, which is of utmost importance in the context of ISO 26262 compliant software development. We will talk about traceability later in the blog.

Talking of ISO 26262 compliant software verification, it is quite like traditional software verification processes. However, there are certain guidelines that need to be followed depending on the ASIL values assigned to the software.

These guidelines not only consist of the recommendation for the methods to be deployed for verification, but also the verification strategy.

Let’s understand this process in detail!

Designing the Software Verification Plan

The test phase of software development lifecycle is defined in Part 6.9- Unit Testing, 6.10- Integration Testing and 6.11- Verification of Software Safety Requirements.

Before this test phase is kick-started, the software verification plan has to be in place. This plan is one of  the work-products of the activities that are listed in the phase called the Initiation of Product Development at Software Level

The following considerations are necessary for designing the verification plan:

  • Activities involved in software development and the methods chosen to perform them. For instance, a software module development can be an activity and Model Based Development can be the chosen method to perform it.
  • The product development lifecycle- that may also be altered according to Part-2 of the standard- Management of Functional Safety
  • Whether the software is configurable; if yes, other considerations may come into picture
  • Methods, programming language, development tools etc. should be consistent across the different phases and sub-phases of the product development lifecycle.
  •  
    Table 1

Following these considerations, a software verification plan is created as a work-product.

The next step is to fine-tune this software verification plan.

After the initiation of the software development lifecycle, the software safety requirements are specified. During this phase, a refined version of software verification plan is generated as a work product.

This refined software verification plan is used as an input(among other inputs) to the software architectural design. This is important because, this design is also to be verified as per the software verification plan.

The following methods can be used for the purpose.

Table 6

After the verification of the software architectural design, a verification report is generated as a work product. This report is one of the evidences presented to prove the ISO 26262 compliance.

Verification of Software Units: An Important Objective of Software Unit Design and Implementation

As per the product development lifecycle, post the design of the software architecture, the Software Unit Design and Implementation process is started. And verification of the software modules (that have been developed), is one of the three objectives of this phase.

As you have been noticing, the work products of the preceding step serve as the input for the next steps. Likewise, during the verification of software units, the inputs are as follows:

  • Software Verification Plan (Fine-tuned during specifying software safety requirement)
  • Software Verification Report (Work Product of Software Architectural Design)

The following table lists the Methods of Verification. The process of verification is as per Part-8 of ISO 26262 standard.

Part 8

At this stage of Product Development Lifecycle, the software unit design is ready to be implemented.

But wait! The software unit now has to go through the rigorous testing processes that comprise Unit Testing, Integration Testing and finally, the verification of software safety Requirement.

The V-Model ensures that each of these tests are performed against their left-hand side counterparts. For instance, Unit Test can be traced to Software Unit Design, Integration to Software Architectural Design and so on.

Understanding Unit, Integration Test and SSR verification Recommended by ISO 26262

The ISO 26262 compliant unit test is quite similar to the regular unit testing. The key difference is that it takes into consideration the software verification plan and report.

Learn more about ISO 26262 compliant unit Testing here- ISO 26262 Compliant Unit Testing Strategies: A Step Towards Achieving Functional Safety in Automotive Product Development

Let’s now move on to the Software Integration Test. The main goal of this phase of testing is to ensure that the software architectural design is fully realized by the developed software.

Details of ISO 26262 Compliant Software Integration Testing

We will not go into the detail of integration testing as it is similar for all software. However, we will try to identify to certain guidelines that ISO 26262 compliant integration testing process is mandated to follow.

  1. The test is carried out according to the software verification plan.
  2. It follows the guidelines described in Part-8 of ISO 26262 standard
  3. The test objects in Integration testing are the software components

In addition to these recommendations, the methods for integration testing is also specified in the standard. These methods are similar for both Unit test as well.

Unit test
  • Requirement-based Test: It that the software requirements specified at the architectural level is met by the software.
  • Interface Test: Interface of one software unit with others is very important and this test ensures that the interfaces are devoid of any errors
  • Fault Injection Test: Arbitrary faults are injected to the software, for instance, corrupting the values of CPU registers, introducing code mutations etc. The software must exhibit intended behavior at such instances.
  • Resource Usage Test: Ensures that the software being tested does not eat up CPU resources which is more than accepted value. Some aspects of this test are performed during system testing (HIL).
  • Back to back Comparison Test: This test comes into picture, when software is being developed using Model Based Development method. The model and code are simulated in a similar way and result is compared.

Are we finally done with the tests here? Apparently No!

Performing all these tests is not enough when it comes to ISO 26262 compliance. In order to evaluate whether these tests have been performed appropriately, some metrics are used.

We call them, Structural Coverage Metrics! Let’s understand them in brief.

There are 2 types of structural coverage metrics:

  1. Functional Coverage: Shows the completeness of the Function that is being tested.
  2. Call Coverage: Shows the percentage of software function calls that are executed. Each function call is executed at least once.

These coverages come under dynamic code analysis and can be performed by tools like CANTATA and RTRT.

And now, we finally, come to the last phase of verification, the Verification of Software Safety Requirement.

Details of the ISO 26262 Compliant Verification of Software Safety Requirement.

The objective of this step is to ensure that the software is able to fulfill the software safety requirements as specified during Software Architectural Design.

The Inputs to this sub-phase of verification are:

  1. Software Verification Plan
  2. Software Architectural Design
  3. Software Verification Report
  4. Safety Plan

And a few supporting information.

The process of verification also involves Hardware-in-Loop Testing, in-vehicle network environment and vehicle environment.

In essence, the test bench that is created for verification needs to include fully or partially integrated vehicle electric system or simulation vehicles.

Conclusion

The stringent verification guidelines recommended in ISO 26262 standard may seem exhaustive, but it is extremely important when it comes to the safety of vehicle and passengers.

Partnering with an expert Functional Safety Consulting team can prove to be a great value-add in achieving the Software Verification objectives in an efficient and cost-effective manner.


  • 0

Integration of FOTA (Firmware-Over-The-Air) Module with Solar Energy Harvesting Platform

 

About the Customer:

Our customer is a Subsidiary of one of the World’s largest Independent Power Producer (IPP) (of Clean and Renewable Energy).

They were actively seeking a robust solution to enhance the efficiency of their field deployed Solar Tracking Systems.
 

Business Challenge:

During the evaluation and PoC stage, a need to remotely update the Field Gateway Device (  Master Controller) software  was realized.

This remote management of the software of the Gateway device was necessary to facilitate the following:

  • Regular Security Patch updates.
  • Update the devices with new version of the software (with latest bug-fixes and feature enhancements).

During software updates of the system, the customer  also wanted to ensure the following:

  • Minimal to Zero system downtime.
  • No impact on the normal operations of the solar harvesting deployments.

In order to meet these requirements, it was decided to integrate FOTA  (Firmware Over-The-Air) update feature with the IoT-powered Solar Energy harvesting System.
 

Embitel Solution:

Once the scope of the project scope was defined, our team started the ground work for FOTA (Firmware update Over The Air) implementation.

The Technology roadmap for FOTA Solution Development roadmap comprised of the following:

  1. Development of Bootloader for firmware reprogramming of the application device (Field Gateway Device/master controller).
  2. Design and Development of the cloud based FOTA image hosting server, which includes:
    • A web server,
    • The application server and,
    • The database server.

    • Following is a representation of the FOTA cloud server architecture:

      FOTA Integration


    • Development of Server Interface (GUI).
    • Integration of communication stacks ( MQTT, HTTPS) for  secure data exchange between server and devices.
  3. Managing the scheduled release of FOTA (Firmware update-Over-The-Air).

    It was decided to schedule all the batch processes of the FOTA update after sunset evenings. Reason – this ensured uninterrupted generation of energy by the solar panels.

    This would also ensure that the FOTA updates are implemented without affecting the normal operations of the Solar Harvesting systems and lead to minimized system downtime.

  4. Implementation of FOTA Event Tracking and reporting , to keep track of successful instances of firmware updates. This feature helped in tracking if the firmware image flashing has failed or download is incomplete.

 

The Impact:

Integration of such a well-defined and robust FOTA update mechanism helped us deliver the following business value-adds:

  1. The Field Gateway Devices are always powered by the latest version of the firmware software. This ensures system security and also enables the devices to deliver a consistent, reliable/fail-safe performance.
  2. The future scope of the enterprise IoT-based Solar harvesting system can be extended anytime to support new feature enhancements and functional improvements through a simple FOTA update.
  3. Enabled a simplified, one-click resolution of critical bugs in the application software.
  4. The controlled and scheduled FOTA release mechanism at non-peak hours helped in minimizing the loss in revenue and performance associated with system downtime.

 

Tools & Technologies:

  • Python: Server Side scripting.
  • Postgress SQL: The database server.
  • Django: Server -side Web framework.
  • Nginx: Web Server.
  • Communication Protocol (Server and Devices):
  • MQTT Protocol: For command exchanges between the cloud server and the field devices.
  • HTTPS: Secure transmission of OTA updates from server to the application devices.


  • 0

What is ODX (ISO 22901) and how it Facilitates Standardization in Vehicle Diagnostics

Category : Embedded Blog

Automotive industry is taking big strides and leaps towards standardization. And rightly so!

It not only brings about the consistency in development of solutions but also ensures increased accuracy and lesser turn-around time.

In the context of vehicle diagnostics, Open Diagnostics eXchange (ODX) is the behind-the-scene hero of standardization.

Defined in the ISO 22901 standard, ODX is an XML based format for defining the diagnostics specifications. An ODX file contains the services of say, UDS (ISO 14229), that need to be implemented for specific automotive applications.

Such a standardized format helps the stakeholders (OEMs, Suppliers and PES companies) to maintain  uniformity in implementation of vehicle diagnostics solutions.

Our latest video on vehicle diagnostics is all about ODX and its role in the standardization and automation in integration of UDS Protocol Stack (ISO 14229).

Key Takeaways from this video on ODX Format

  • What is ODX format?
  • The need of ODX in standardization and automation of vehicle diagnostics implementation
  • How ODX helps in powering UDS implementation
  • The Value-Adds of ODX format of diagnostics specification

The video helps in establishing a preliminary understanding of ODX format on which, more expertise can be built.

Engineers who work on vehicle diagnostics implementation can consider this video to be a gateway to ODX.

Even the business managers and decision makers in automotive and Product Engineering Services company will find this video useful for understanding ODX.

Watch and like the video and share with your colleagues as well!


  • 0

What is Open Diagnostics eXchange (ODX) and How It Enables Standardization in UDS Based Vehicle Diagnostics

Category : Embedded Blog

In an industry like Automotive, the value-chain is tightly-coupled and multiple stakeholders are involved in design and development of any product.

From component suppliers to Tier-I/Tier-II electronics suppliers to product engineering services providers to OEMs’ (didn’t we mention that the value-chain is also very exhaustive)

In such a tight-knit industry, where the overall success is defined by the efficiency at all the levels of the supply chain, Standardization in the processes of operations, design and development methods is an absolute must.

The goal of this Standardization is to enable forward and backward compatibility, across the supply-chain.

Hence, one will observe abundance of this much needed standardization, across the automotive industry, in avatars like AUTOSAR Architecture, ISO Standards and more.

In this blog, we will throw some light on standardization in Vehicle Diagnostics and how ODX (Open Diagnostic eXchange) Format is the hero of this standardization.

What is ODX format?

The ODX format is standardized in ISO 22901 Standard and is an XML-based ASAM standard for describing ECU (electronic control unit) diagnostic data.

Using this uniform OEM-independent format, OEMs’, ECU Suppliers (Tier-I Suppliers), and testing equipment manufacturers can describe and exchange ECU diagnostic data, without any compatibility issues.

Whenever distributed teams are involved in projects, this standard becomes a good choice for exchanging relevant diagnostic information. This enables all the stakeholders to use the shared diagnostic data across geographies.

Understanding the Structure of the ODX Data Model

At the foundation of ODX lies a data model which is formally specified using UML class diagrams. Once specified, the data model is mapped to XML. This ODX data model is partitioned into four main areas:

  • Diagnostics Communication: Communication between an external device and an ECU or a group of ECUs to enquire diagnostic information and/or to modify the ECU’s behavior for diagnostic purposes.
  • ECU Memory Programming: Read or write access to the ECU’s flash memory.
  • ECU Configuration: Data records and their properties for ECU variant coding.
  • Function Dictionary: Mapping of individual ECU diagnostic messages and data for the purpose to carry out diagnostics on a functional level.

ODX is independent of vehicle diagnostic protocols. It is compatible with most diagnostic protocols in the automotive industry and is specifically used with KWP 2000 (ISO 14230), UDS (ISO 14229), SAE J1939 protocols.

The need for a standardized Diagnostic Specifications format

In the automotive sector, a Diagnostic Design Specification is a document which describes ‘how diagnostics will be implemented in the systems being developed by an organization’.

This is the reference vehicle diagnostics related document used at every stage of development, right from high-level design to system testing.

Traditionally, the diagnostic functions of early ECUs were straightaway implemented in the software and documented as part of the software documentation.

However, this trend has now changed, and diagnostic specifications are before the onset of product development.

A well designed system is always backed by clearly stated diagnostic specifications. ECU diagnostic specifications are expected to be clearly defined for the software development teams

Since the advanced electronics have increasingly made ECU a complex system, the need for automating this process of drafting diagnostics specifications was felt.

In addition to this, more often than not, OEMs’ relied on either basic document formats like DOCX, XLSX, PDF, or proprietary documentation formats to share diagnostic specifications with the software development teams.

To better streamline the operations and also introduce automation, the need for a standardized approach was felt. This standardized would let the diagnostics specifications be automatically entered into the configuration tools of the ECU life-cycle. This need for standardization triggered the development of the ODX standard format (Open Diagnostics Exchange Format) which was formally released in December 2000.

How is ODX Generated?

The generation of ODX can be understood by looking at the first cross-OEM ODX project that was carried out between two leading vehicle manufacturers from 2003 to 2006. The CANdela tool chain was used in the project and it involved two vehicle models. The following procedure was followed:

  1. CANdelaStudio was used to create the diagnostic descriptions based on a given template (OEM1)
  2. Thereafter, ODX data was exported using CANdelaStudio
  3. Then the supplier used CANdito / CANoe to perform diagnostic testing of the ECU and parameterized it using CANdela CDD data
  4. Finally, the tester was parameterized with ODX data during in-vehicle diagnostic testing (OEM 2)

This project was carried out using ODX version 2.0.1.

How ODX Aids in Configuration of UDS Services?

Manual configuration of UDS protocol services, diagnostics specifications (provided by the OEM) can be very time consuming and may suffer from the risk of manual errors.

With the advent of ODX, automated tools are also available, that facilitate the configuration of UDS protocol stack.

The diagnostic specifications are provided as input to the ODX tools to generate XML-based ODX files. These files then can be referred to during the development, testing, and validation phases.

The ODX files can also be used to automatically generate configuration files (.c and .h files), required for UDS diagnostic specifications.

Benefits of ODX for the automotive industry

Because of the uniformity it brings in the different phases of vehicle diagnostics configuration, OEMs, suppliers and technology providers observe a wide range of benefits

  • The description of ECU diagnostics data can be done in a standardized format
  • The same ODX file can be shared within development, production, service, and validation teams, so that all teams have a single source of information and everything happens in a smooth manner without any discrepancies
  • The ODX file’s XML description can be used to generate documentation
  • Diagnostic data verification takes lesser time and effort
  • Lesser number of errors as a standard diagnostics data format is used across the teams

In order for the OEMs and the product engineering service teams to use ODX format with ease, there are several tools to choose from. Irrespective of how ODX format is implemented for vehicle diagnostics (UDS), it is going to bring in the much needed standardization among the automotive stakeholders. It is also likely to expedite the process of vehicle diagnostics configuration by automating it.


  • 0

How IoT Technology Stack Enables Efficient ‘Tracking & Harvesting’, in a Solar Energy Harvesting Solution

Category : Embedded Blog

One of the most fascinating and innovative use-cases of how IoT can help in improving the RoI and system efficiency is that of an IoT powered Solar Energy Harvesting Platforms.

The core objective of a Solar Energy Harvesting solution is to maximize energy harvesting capability of the field-deployed solar panels.

In order to ensure that solar panels are able to deliver optimum Solar Energy output, it is imperative that they are made to align with the sun’s trajectory throughout the day.

The conventional solar energy harvesting solutions are faced with various challenges that limit their overall efficiency. This includes:

  • Adjusting the inclination of the numerous field-deployed solar panels in tandem with changing position of the sun
  • Efficient maintenance and damage protection of the field deployed solar panels, especially in situations like heavy windfall and rainfall.

This is where an Internet of Things (IoT) delivers unmatched value-add!

But how? Watch the video to understand:

(Video to be embedded here)

What is the Video All About?:

The video gives a sneak-peek into the technology stack of an IoT-based Solar Energy Harvesting solution. It also offers an insight into:

  • Critical functions performed by IoT powered Solar Energy Harvesting System
  • How Data flows between the fundamental components of the system to enable efficient harvesting of solar energy.
  • This Part-1 of the video series focusing on the Solar Energy Harvesting System. In this part 1, we focus on how the system performs efficient “ Tracking and harvesting of solar energy” .

    In the next part, we will discuss about the third main function that is “SCADA based remote monitoring” of the field deployed Solar panels.

    Hope you find this video series interesting and helpful. Show us some love through likes, comments and sharing of the video . Also , please don’t forget to subscribe to our YouTube channel!


    • 0

    The Success Story of How We Delivered a Digital Instrument Cluster for Electric Scooters

    Category : Product Engineering

     

    About the Customer:

    Our customer is one of the most loved and trusted name in consumer electronics goods

    Innovation beyond the comfort zone’ being their motto, our customer embarked on this new journey of design and development of Electronic Digital Instrument Clusters for the Electric Two-Wheeler industry.

    This idea of a multi-functional instrument cluster germinated to take the form of full-fledged a platform solution that can be customized for Electric Two-Wheelers, for global OEMs.
     

    Business Challenge

    As the customer was new to automotive products, they needed technology partners (software and hardware). Embitel, as an organization with extensive expertise in both Automotive and IoT, proved to be the best suited for this project .

    Our customer had successfully and carefully crafted the product development roadmap for this one of the kind project.

    During this process, our customer realized the need for expert technology partners, who can effectively contribute in transforming this idea of digital instrument cluster into a business reality.

    The following challenges, made it absolutely essential to partner with a Product Engineering Services provide, with domain knowledge of Automotive:

    • Our customer, a major player in consumer electronics, was taking its first step into the world of automotive product development.
    • This required expertise in automotive grade microcontroller platforms, base software (HAL+low level device drivers and more) development, FOTA (Firmware-over-the-air), Flash Bootloader software development and integration, and more.
    • The customer also had a long-term vision and desired to develop a scalable digital instrument cluster solution, so that new features can be easily added in the future.
    • Another major challenge associated with the project was time and BOM cost that had to be kept under check. This was important as it would have direct impact on the cost of the two-wheeler.

    Embitel Technologies , with the extensive expertise in both Automotive and IoT (Internet of Things), was entrusted to join hands with the customer as their R&D and Engineering Services Partner.
     

    Embitel’s Solution

    Our tech team was provided with only an outline of the solution and we were expected to come up with the Requirement Specifications.

    In essence, we were their R&D partner, collaborating with the customer’s in-house teams in research, design and development of their product (digital instrument cluster)

    Digital Instrument Cluster

    We partnered to develop the end-to-end solution, including the hardware and the software components.

    The following applications were developed as functionalities of this solution.

    • Software Features designed for the Connected Digital Instrument Cluster:
      • LCD display
      • Phone & Cloud Connectivity
      • Navigation
      • Alert and Warning
      • Firmware Over-the-Air (FOTA)
    • Embitel’s Role in Hardware Design and Development:
      • Evaluation and selection of Microcontroller Platform.
      • Designing of the hardware schematics
      • Hardware Testing as per standards such as ISO 7637 and ISO 16750, in order to ensure operability in high temperatures
      • Designing a scalable hardware platform with additional pins to accommodate new features to be added in future
    • Embitel’s Role in Software Design and Development:
      • Development of BSP & Middleware Software Modules
      • Development of the software components and device drivers, to support all the desired features and functionalities
      • UI/UX Design and Development

     

    Embitel’s Impact:

    Our customer benefited from our solution in more ways than one.

    • Reduced BOM cost due to flexibility in HW/SW configuration
    • Embitel’ s library of reusable components like Flash Bootloader, base software modules etc. reduced time-to-market
    • Our cross-functional teams (Automotive + IoT) worked parallelly on multiple functionalities to reduce the development time
    • We were successful in achieving our customer’s objective of launching a Connected Digital Instrument Platform

     

    Tools and Technologies

    • AUTOCAD: It was used to design the UI for instrument cluster LCD screen. It gave the output in DFX format, ideal for the project.
    • Cadence Designing Tool: The tool was used for PCB Designing, schematics, and simulation of hardware components

    • 0

    Development of a Motor Controller and an Application Layer (using MATLAB), for a BLDC Motor

    Category : Product Engineering

    About the Customer:

    Our customer is a leading Japanese OEM of Electric Motors. Their products find application in hard-disk drives, electric appliances, automobiles, and commercial and manufacturing equipment.
     

    Business Challenge:

    As part of the automotive product development roadmap, the customer desired to design a motor controller solution for a Brushless DC (BLDC) motor. This motor control solution, along with the motor, was to be integrated with the transmission control unit (TCU) product line.

    The in-house product development teams of our customer had in-depth expertise and experience in hardware design and development. But the in-house teams faced several challenges during the software development lifecycle. Our customer realized how critical is the software design in building an efficient motor control solution and in achieving the desired speed-torque characteristics.

    During the time when our customer confronted this challenge, they were already partnering with Embitel Technologies for a Functional Safety Project. Based on this partnership, our customer had developed a lot of trust in software development capabilities of our Automotive Teams. This ensured that our partnership with the customer was further strengthened and our teams took up this challenge of designing an efficient BLDC Motor Control Solution.
     

    Embitel Solution:

    • The Development team at Embitel proposed the use of MATLAB (Model Based Development) for developing the application. This was suggested so that the developers could simulate the actual motor in MATLAB and ensure that it showed intended behavior before actually implementing it within the Transmission Control Unit.
    • In order to reduce the turn-around time, we deployed SimScape, which are readymade simulation modules that need some tuning for specific use-cases. These modules were able to simulate the real scenario so that developers were required to only work on the base application.
    • Real motor parameters were found out by consulting with experts and technical papers. These parameters were then fed to the simulators and output graphs were checked. We also fine-tuned the PI gains to get the real speed-torque curve. The best practices suggested by MATLAB, Mathematical calculations and models were used to arrive at the correct parameters and then they were used in the development.
    • Reducing the hardware components was also one of the value-adds our customers expected from us. Our engineers used one-shunt resistance for current reading. Using one-shunt resistance with a three-phase motor can get very  tricky because it is difficult to find out the current from which phase is going through the shunt. Our Motor Controller development team design an algorithm to determine how and where to sample the current. This was the toughest part of the solution.
    • Another major part of the project was to integrate the base software of the motor (BSW) with application generated by MATLAB. BSW included low level drivers (MCAL), Hardware Abstraction Layer (HAL), diagnostics UDS stack, scheduler, and flash bootloader software 
    • Read-to-deploy and production-grade UDS Protocol Stack (ISO 14229) and Flash Bootloader software (for ECU reprogramming) proved to be value-adds for our customer. These re-usable software components ensured cost and time savings for the overall project.

     

    Embitel’s Impact:

    Our Automotive Teams were successful in delivering a motor controller solution with the required speed-torque characteristics.
     

    Tools and Technologies:

    • Hardware Platform: Infineon
    • BLDC Motor: 400 watts
    • MATLAB and SimScape
    • Integration of our proprietary and production-grade UDS Protocol Stack (ISO 14229) \
    • Current Reading Algorithms

    • 0

    [Vlog] Model Based Development Tutorial: How to develop Models using MATLAB-SIMULINK tool

    Category : Embedded Blog

    Model Based Development (MBD) revolves around ‘Models’! Models in MBD universe are diagrammatic representation of the real-world system, that developers are intending to build.

    However, the models are not just your regular diagrams. They contain the logicand have the capability to generate code and that too, at a click of a button.

    Some specialized skills are required to build Models. Especially, if you are involved in model based development of automotive applications.

    So how are these models built? What are the tools that help build these models? What are the inputs and the outputs?

    Our latest video gives an insight into all this and more.

    We also have a detailed tutorial on ‘How to Create Model using MATLAB-SIMULINK’. Do check it out.

    Key Takeaways from this Model Based Development video:

    • Understanding Models in Model Based Development
    • Snapshot of the Model creation in our model based development flowchart
    • Tools required for Model Development
    • Prerequisites of Model Development
    • Step-by-Step process of Model Creation using Simulink

    Our previous two videos on Model Based Development gave a high-level idea of how it works and what are the value-adds.

    In our latest video, we have dived deep into the world of MBD and tried to explain the very first step of model based development paradigm- the model creation.

    We will be out with more such videos in order to explain the next steps involved in model based development process. Stay Tuned!

    If you like the video, don’t forget to show your love by hitting the like button. This video might help your colleagues too, so do share within your network. And lastly, subscribe to our YouTube Channel to be the first to get updated on new videos.

    Happy viewing!


    • 0

    [Infographic Inside] V-Cycle of ISO 26262 Compliant Software Development

    Category : automotive-insights

    ISO 26262 Infographic

    Development of ISO 26262 compliant software calls for expertise in certain recommended tools and work-products (evidences for ISO 26262 compliance). Our latest infographic aims to unravel both these important aspects of functional safety compliance (ISO 26262).

    This infographic will introduce you to the set of tools popularly used at each stage of ISO 26262 compliant software development. A few of them like CANTATA are recommended by the ISO 26262 standard itself, while others are industry-wide used and accepted tools. The work products generated at each stage of V-cycle model have also been highlighted for your reference.