WP_Term Object
(
    [term_id] => 159
    [name] => Siemens EDA
    [slug] => siemens-eda
    [term_group] => 0
    [term_taxonomy_id] => 159
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 716
    [filter] => raw
    [cat_ID] => 159
    [category_count] => 716
    [category_description] => 
    [cat_name] => Siemens EDA
    [category_nicename] => siemens-eda
    [category_parent] => 157
)
Q2FY24TessentAI 800X100 
WP_Term Object
(
    [term_id] => 159
    [name] => Siemens EDA
    [slug] => siemens-eda
    [term_group] => 0
    [term_taxonomy_id] => 159
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 716
    [filter] => raw
    [cat_ID] => 159
    [category_count] => 716
    [category_description] => 
    [cat_name] => Siemens EDA
    [category_nicename] => siemens-eda
    [category_parent] => 157
)
Siemens EDA
Posted on by Bernard Murphy

Minimizing MCU Supply Chain Grief

Minimizing MCU Supply Chain Grief
by Bernard Murphy on 11-11-2021 at 6:00 am
Categories: Automotive, EDA, Siemens EDA

I doubt there is anyone who hasn’t felt the impact of supply chain problems, from late ecommerce deliveries (weeks) to kitchen appliances (up to 6 months or more). Perhaps no industry has been more affected than auto makers, whose cars are now critically dependent on advanced electronics. According to a white paper recently released by Siemens Digital Industries Software, there can be up to 150 electronic control units (ECUs) in a car, dependent on microcontroller devices (MCUs) whose delivery is suffering just these problems. Which is driving automakers and suppliers to accelerate other aspects of development or redesign these systems around alternative MCU devices.

Minimizing MCU Supply Chain Grief

Workarounds

In simpler times there was a concept of “second sourcing”. If your product was critically dependent on some device, you had a preferred source for that device plus a plan B option delivering more or less identical functionality. Like Intel and AMD for processors (not necessarily in that order). But now products and devices are more complex, and both evolve more rapidly. Suitable plan B options don’t just evolve through market forces, they must now be considered up front.

In the case of MCUs for automotive applications, Siemens suggests three options:

  • At minimum, allow software development to progress while you’re waiting for MCU deliveries. Developing, debugging and qualifying the software for the ECU is a big task in itself. You can progress on all those tasks by running on a virtual model of the ECU before you receive MCU shipments.
  • Plan for a replacement MCU. Perhaps lead times and/or uncertainties for your preferred option are too risky to meet your market objectives. You want to switch to an alternative. That may require some software redesign to deal with incompatibilities between the two devices
  • And maybe, while you’ll figure out a path through one of these two options, you’d like to reduce your exposure to similar risks in the future. By developing against a hardware independent software interface widely accepted in the industry – AUTOSAR.

Early development before hardware arrives

Siemens suggests their Capital VSTAR platform to support all three cases; this platform is built around the AUTOSAR standard. The flow front-end is the Capital VSTAR Integrator which will includes an ECU configuration generator to process input from upstream development tools ad to configure the VSTAR platform. This also provides support for application software components.

The heart of the system is the Capital VSTAR Virtualizer. By default, this will run application software against a generic virtual MCU and I/O model. This is ready to integrate with the supplied AUTOSAR RTE, OS, basic applications and the AUTOSAR MCU abstraction layer (MCAL). Considering the first option above, software developers can build and test almost all their application software against this generic model, before they even see hardware for the MCU. They can run virtual hardware in the loop testing, network testing over standard auto network protocols like CAN and FlexRay, and run diagnostic and calibration checks against standard tools.

When ready to test against a specific MCU virtual model, developers can replace the generic model with a targeted model. This they can also extend to model ECU-specific characteristics. This method supports both first and second options above – either refining the generic model to a target model or switching out one MCU model for another.

De-risking through AUTOSAR-compliant development

Finally, since the Capital VSTAR platform is based on AUTOSAR it encourages development to that hardware independent standard. In future you limit your risk in switching MCU devices to just what is unique in the MCAL layer. This is a much simpler rework if you ever need to switch again 

Siemens adds that they are experienced in providing expert engineering services to help mitigate risks in changing device platforms. From performance through safety, security, communications, diagnostics and calibration. You don’t need to figure out how to mitigate supply chain problems on your own!

You can learn more about Capital VSTAR from this white paper.

Also Read:

Back to Basics in RTL Design Quality

APR Tool Gets a Speed Boost and Uses Less RAM

DARPA Toolbox Initiative Boosts Design Productivity

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.