Software Development of Battery Management Systems – Model Based Approach
Training Duration: 5 days
Day 1: Introduction to Model Based Development and BMS Domain Knowledge
A battery management system is essentially the brain of a battery pack; it measures and reports crucial information for the operation of the battery and protects the battery from damage in a wide range of operating conditions. We will discuss important functions like cell protection from overcharging/over voltage/ discharge, energy management, cell balancing, etc. and how to implement these in software.
Day 2: AUTOSAR for BMS
The primary goal of the AUTOSAR partnership is the standardization of a common methodology, basic system functions and functional interfaces. The idea is to reuse software components so that the rising complexity can be handled, and development efficiency can be substantially improved. As we see this shift from an ECU-based to a function-based system design, automotive suppliers are seeing increased demand from OEMs for modular, standalone software solutions.
We will discuss;
AUTOSAR 3.2, 4.0.3 & 4.2 software development using tools like Vector DaVinci developer/configurator, GENy.
Development of AUTOSAR BSW (System Services, Memory, Communication, & Input/Output).
AUTOSAR software components configuration and RTE.
AUTOSAR BSW and MCAL Integration.
Implementation of Diagnostic Services (UDS) – (DCM, DEM).
AUTOSAR compliant code generation from Simulink & Stateflow models using TargetLink
Day 2: ISO26262 for BMS
ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems. ISO 26262 addresses possible hazards caused by malfunctioning behaviour of E/E safety-related systems, including interaction of these systems.
The current ISO 26262-6:2011 specifies the requirements for product development at the software level for automotive applications.
We will discuss:
Specification of the software safety requirements
Software architectural design
Software unit design and implementation
Software unit testing
Software integration and testing
Verification of software safety requirements
Day 3 & 4: Requirements Engineering
The process of requirements specification is probably the single most important step in an embedded software project. When requirements are poorly captured or managed, scope creep can occur and put the project’s success in jeopardy. For this reason, all requirements need to be formally captured (vis. ISO26262) in a detailed document and cleared from customer and supplier sides.
We will discuss;
Usage of semi-formal methods (e.g. requirements models)
Usage of formal verification (Model checking)
Observing the requirements coverage
Structural test methods extend the functional tests
Automated test generation
Minimizing all manual steps
Usage of SW development methodologies on system level
Day 5: BMS Architecture Development, Implementation & Testing
Software architecture is a plan that that takes into consideration, all kinds of specifications, components, communication between components, external dependencies, implementation guidelines, risks, and many more aspects. It forms the basis for communication between all the stakeholders and importantly it ensures transferability, scalability, flexibility and maintainability of the architecture/model.
We will discuss;
Use of Enterprise Architect to develop Model-Based architectures
Use of MATLAB-SIMULINK designs to formally describe components and interfaces.
Fully automated Back-2-Back testing between Simulink/TargetLink models and production code.
Generation of structural tests for full code coverage up to MC/DC.
Automatic execution of test cases in MIL, SIL or PIL as per ISO 26262 requirements.
HIL Testing with BTC EmbeddedSpecifier with dSPACE “RTT Observer Library”