Managing the Deluge of Data

The model-based development (MBD) process has been a key enabler of technical advancement in the transportation industry; however, the MBD process leads to the generation of large volumes of data artifacts and work products. To maintain efficiency while continuously improving the quality of products, it is necessary to be able to manage this data in an efficient manner.

February 1, 2014

The software development process known commonly as the V-Cycle for model-based design has served the transportation industry well for managing the complexity of systems. However, given the large scope of development, the process is reflected in organizational structures with large independent departments, in many cases spanning across the globe, performing specific activities within the V-Cycle. The risks in product development come from many different areas, and the ISO 26262 standard has identified traceability of requirements throughout development as one key methodology to reduce risk. However, in the model-based development (MBD) process, this task has been difficult. Given the large number of product versions, variants, and platforms, connecting this information to all the work products in the development process is a major challenge.

dSPACE’s SYNECT is a data management and collaboration software tool for use with model-based development and ECU testing.

Requirements-based development and testing is the common approach taken in developing embedded software across the industries. These requirements are recorded in many forms, starting with simple documents to formal machine readable descriptions. These requirements then drive the development activities and are necessary to be tracked throughout the development process. A good requirements-tracing system serves many key elements of software implementation:

Provides methods to ensure all the requirements are met
Provides methods to ensure that there is no unintended functionality (one that cannot be traced to a requirement) in the final implementation
Provides methods to assess the impact of change in requirements on the development activity.

Thus, a primary element in data management is a good requirements repository (integrated or independent) and mechanism to trace development data and artifacts to these requirements.

Following the requirements, it is typical to develop the software architecture and define data interfaces between software components residing on the same electronic control unit (ECU) or multiple ECUs connected with communication networks such as CAN, FlexRay, LIN, etc. As we can see, we are already developing data about software architecture (models) and interfaces (data types, lengths, timing, dependencies, validation, etc.) that have unique forms and meanings in the world of MBD and its necessary tools. It is important that this data is packaged appropriately for use in the downstream development processes, while maintaining links to requirements, versions, variants, etc. In the rapid controls prototyping stages, where the engineer develops and verifies the desired feature functionality as per the requirements, MBD plays a significant role. Several variants of control algorithm models and plant models are developed. The iterative process generates even more versions for each of the system variants. Additionally, there is a significant amount of data generated through data capturing during experimentation and validation that may be a significant source of information for validating the final production intent software. A testing method, commonly referred to as back-to-back testing, requires that such test data be retained. Again, there are various artifacts, such as controller models, parameter sets, and tool-specific artifacts (such as experiments, instrumentation layouts), along with test result data, that get generated.

Using model-based development (MBD), the development artifacts and data associated with each evolution can grow in multiples at the rate of product evolution. Shown is the iteration of use for Product Lifecycle Management (PLM), Application Lifecycle Management (ALM), and MBD Systems.

In the production-intent implementation of software, specifications in the form of an executable model are handed down to the code development team. These engineers then adapt the implementation of models with production-intent ECU specifications, which are not only hardware specific, but may also contain AUTOSAR (Automotive Open System Architecture) standard-specific requirements. This results again in more artifacts, and testing yields further data. Additionally, the data used in the final implementation is unique with specific identifiers, types, etc., and is typically handled in special data dictionaries. Managing this data in the context of the overall MBD process, requirements, variants, and versions is an important task. Knowing which parameters resulted from a specific software product release version and its origination from requirements is an important trace from product quality, as well as a liability perspective.

The next step of software development is the critical step of validation and verification of software as a component, as part of a subsystem, and then finally as full integration with the entire vehicle or at the system level. This involves a very comprehensive and sophisticated test infrastructure that includes complex HIL test systems, plant models, test automation tools, test suites, ECUs, system components, etc. With ever increasing consumer demand-driven flexibility in product features, a number of possible product variants are catered through the software. This results in an exponential increase in tests, test infrastructure configurations, and data.

The MBD process yields artifacts and data in large volumes requiring appropriate management.

Achieving development efficiency

Variants of systems are defined via their points of variation, constraints between variants, and the allowable variant configurations.

One of the key features of MBD is that it brings clarity and transparency to the development process. Another significant benefit of MBD is not only the resulting efficiency gain from first-time development, but the efficiency gain that is possible through the reuse of artifacts and data. This is where the investment in the MBD-based tool chain results in significant payback for various industries, including automotive, aerospace, and commercial vehicle.

While independent tools, together with solutions for version control, provide some mechanism to store various artifacts and enable reuse, they do not provide full visibility and traceability of artifacts with requirements, variants, and versions of the end product. This is necessary as products undergo incremental change to understand exactly the impact on artifacts in the development process and to only address those that are affected. In doing so, it automatically creates a reuse mechanism where the incremental development is based on the work that has already been established. Any creation of new artifacts, if necessary, then can be archived in a similar manner for future work.

Data management is not a big topic from the IT perspective. There are a lot of data generated in organizations that are managed/maintained by various IT systems. Similarly, with the use of computer technology in product design and development over the past two decades, we have also seen the matured use of Product Lifecycle Management (PLM) and software Application Lifecycle Management (ALM) tools. However, with the increase of software component products through mechatronics and the use of MBD to develop those software components, organizations are facing new challenges as MBD process data and artifacts have unique characteristics. Just creating meta-data to connect the dots does not resolve the main issue of adding context (appropriate information and meaning) to data to give clarity to the engineers involved in the product development activities.

The structure of the dSPACE SYNECT implementation with a database layer using the SystemWeaver Database Management System is shown.

File formats, as agreed upon through the acceptance of various standards such as ASAM MCD3, AUTOSAR, etc., and industry practices, have to be supported and understood for appropriate handling in the data management solution. For example, it should be possible to use the parameter set created in a particular format during the prototyping phase for other activities—maybe in other formats with different tools, while maintaining traceability. Industry standard-based data formats result in providing tool connectivity and interoperability. It is therefore important that the database solution support the relevant standards and be able to transform data as necessary. Additionally, there are always tool-specific artifacts/work products that will remain in that specific environment. However, it is still important to be able to record and provide traceability to these items through the database solution.

Integration of MBD tools

The MBD process has a very wide scope in the design of mechatronic systems in the commonly described V-Cycle. These process phases are aided with numerous tools in each phase, increasing efficiency along the way. Automotive OEM and supplier tool chains vary from a few to hundreds of tools. Achieving consistency and traceability of data across such tool chains is a challenge. However, proper identification of the development process data needs, exchange of appropriate information with supported formats, and adherence to standards should help in creating tool connectivity. A common data repository that supports relevant standards and data exchange mechanisms would automatically provide tool connectivity. As long as individual tools continue to support the standards, the connectivity to the database would be implicitly managed.

Traceability from requirements to test results helps track the work performed during the testing process.

In the overall product lifecycle, various components of the system undergo evolutions at different rates. Some components may never change throughout the life of a product, while others may undergo several changes. In today’s mobility systems driven by mechatronics, the software components undergo continuous evolution, probably at the highest rate than any other component in the system. Additionally, using MBD, the development artifacts and data associated with each evolution can grow in multiples at the rate of product evolution. Tracking these many intermediate-level artifacts in the overall PLM tools seems implausible. PLM and ALM tools deal effectively with finished components, rather than process-oriented work products. As a result, management of data in PLM/ALM tools should be inherently different and may not be compatible with the process needs of MBD. Therefore, a special data management solution that supports model-based design, with its inherent nuances, standards, and work processes, is necessary. The resulting end products of this tool chain are software components that can be managed in the ALM and further in PLM tools.

For a MBD management tool to be effective, many different tools and file formats and interface standards need to be supported. Most companies use a diverse set of tools and file formats that require an open and extensible system architecture. Furthermore, the management tool must be configurable and flexible enough to handle designing interfaces to model and test tools and other data systems, so that different tools can be effectively interfaced and share operations and data, thereby eliminating the tedious manual processes for data transfer and tool execution.

This article is based on SAE International technical paper 2013-01-2398 by Mahendra Muli and Jace Allen of dSPACE Inc.