Reading Time: 4 min
Sophia Suo, Head, Electrified Powertrain, KPIT
Geetha Srinivasan, Chief Architect, Powertrain, KPIT
This is where a platform-led approach for software integration in EVs can ensure improved validation, enhanced productivity and reduced costs over the program lifecycle while effectively meeting critical safety, function and timing demands. In this context, AUTOSAR emerges as a standard interface for components even as it ensures their reuse and management across platforms while protecting the intellectual property of each party.
In this webinar, KPIT’s Sophia Suo and Geetha Srinivasan discuss the challenges and analyse the software development and integration journey for EVs from prototype-to-production while offering insights into KPIT’s holistic solution.
Even as EV tech swiftly evolves, it faces not just architectural complexities but other hurdles in making a concept-level technology, production-ready. OEMs hardware samples typically undergo evaluations starting with — the B sample (functional) followed by the C sample (design verification and validation for design concept), the manufacturing process validation and finally, the final production.
Likewise, the Tier 1s have similar milestones to align component maturity and vehicle samples. The entire process entails multiple steps and iterations from B to -D sample stages, in addition to frequent software releases at a fast pace that often destabilise both, Tier 1s and OEMs. Also, increased inputs from OEMs and Tier1s, constant architecture changes, program management and multiple V-cycle verification and validation during the sample stages pose huge challenges for software integration.
Hardcore embedded systems have proved themselves in the legacy systems yet the architecture needs to evolve to accommodate challenges over time to:
Platform-based development is key at the:
In case of a single-core architecture, the performance measurements from that system are taken as the input. This is followed by data profiling before partition definition is finalised or interface speculation occurs. Mapping components to cores and cores to partitions is key. Subsequently, component clusters are built to look at memory handling, task execution and read-write access consistencies for data-sharing and finally, the multi-core architecture is determined.
Data Profiling and Component Coupling: How to Quantitatively and Qualitatively Assess Existing Architecture to Derive Multi-core Software Architecture?
This entails: Define the interfaces, components and access rate. Feed this into a dependency matrix simulation environment. Derive the coupling factor and coupling index for each component, which cannot be split across the partition. Cluster them and finally, derive the amount of shared data required to be taken care of for concurrent access from multi-core scenario.
It’s important to acquire the function safety analyses early on so there is clarity on components that are ASIL- driven, for example, so safety is not compromised. Then, derive the allocation concepts along with the multi-core migration guidelines before finally, getting the safety test cases.
A software integration partner with years of experience working on numerous production programs accelerates the development process by fine-tuning the:
KPIT’s time-tested and holistic approach to challenges across sample and production-ready prototype stages entails – ready frameworks (SOTA cybersecurity-compliant), libraries (Safety, MIL, SIL), platforms (with generic requirement specifications) and accelerators for key electric vehicle components like (Charger, Inverter, BMS and VCU.). Its suite of solutions spans a host of architecture guidelines and health evaluations, DFA templates and methodology, automated checks and proven ePT software components. Leveraging KPIT’s comprehensive capabilities here can significantly assist redressal of growing software architecture complexities revolving around changing requirements, delivering on time and verification and validation depth and coverage.
Reading Time: 4 min