Managing detailed development data
in a PLM framework
Managing detailed development data
in a PLM framework
Jan Söderberg, Systemite AB (presenter)
Peter Thorngren, Volvo GTT
2
nd
Interoperability for Embedded Systems Development Environments
Jan Söderberg, Systemite AB (presenter)
Peter Thorngren, Volvo GTT
Complexity – Scale, contd.
Complexity - Product Line
130+ Specifications
and Reports
10+ Products
40+ Test
Suites
Complexity - Change
> 2000 Change
Requests per
Baseline
Complexity – IT Environment
API
MQ
MQ
API
API
Automated File Mgmt
”Gimme All Your Requirements”
§
§
§
§
§
§
§
§
Which requirements?
Sample Meta Model, around Requirement
§
Functional
Requirement
Which System?
Which Status?
(Approval, Test status
etc)
Integration Case – Automated Test Environment
Test
Scope
Test
Suite
Test
Test
Spec
Test
Case
Test Case Status Test Case Sub Test Suite Test Scope Test SpecificationTest Specification Test
Require-ment
Item
Artifact
Test SystemArtifact
System Under Test Specifying Item Test Specification Requirement Test Case Requirement SpecificationIntegration Case – Automated Test Environment
Customer Test Execution
application PNTool
SystemWeaver Test Development
& Management
Integration based on:
• Open meta model, based on
EAST-ADL and custom extensions
Findings
Indeed possible to support embedded systems
development in a PLM framework like SystemWeaver
- even on a detailed design level
Tool integration can be done by file exchange or API
integration
OSLC can be a new alternative for integration
Integration without open meta models and
onthologies is extremely difficult and pointless
Development of complex systems is typically not managed in PLM systems today. Examples are development of software, embedded systems or test automation. The approaches used instead are mostly based on file based version control or custom solutions. A reason for this situation is that many development tools are still file based, and the scale of individual development activities are small enough to be carried out in the traditional approach. However, the growing scale of systems like automotive electric/electronic systems, the tight schedules in large development projects, and the need for integration and collaboration between different
development activities has made the traditional approaches less feasible. In this paper we will look into the problem, and describe why the file based approach faces substantial challenges and why the PLM approach is promising, using an industrial case as an example.
In traditional file based development individual artifacts are defined in separate files. File based versioning can keep track of changes and versions of such files. It also offers basic configuration support, usually using some label mechanism, where different files included in a configuration are tagged with a label representing the configuration. A limitation with this approach is that the actual system configuration has to be built outside the versioning system by using some build mechanism, like the traditional ‘make’ command for software. Such built configurations then exist only in the PC or workstation of an individual developer, and changes to any of the (source) files have to be checked in to the versioning system. This approach works well for development of software where an individual developer can develop a module of the software contained in a file, for a period of hours or days. This level of granularity and level of collaboration is not enough for a complex system or system-of-system context.
An example that stresses the need for efficient data management is testing of large systems. The challenge here is due to the results of several processes that meet and touch in the testing activities; the test cases, the specifications that are used as references for the test cases, the artifacts comprising System Under Test, the test environment and equipment to mention the most important. The realization of individual artifacts is typically uncorrelated, on the scale of time relevant for testing activities: new artifacts arrive every day, requirements and test cases constantly change, and regression tests have to be performed daily. The rate of change means that formal waterfall or baseline based configuration management is not effective, since there will be many changes included within each iteration, between each formal baseline. The rate of change means that test data representing the developed system will change from one second to the other. This also means that defining configurations based on labels and performing check out, check in, and merge operations, which are required for file based configuration and management, no longer work.
An alternative solution is to use a PLM approach where all information is managed in a coherent framework. In this approach the actual system configuration, for example as defined by requirements, test cases and test results, is explicit in the PLM system, with no need for a separate build process. By direct access to the representation of the developed system in the PLM system, data produced by test activities can update the configuration in real time. This kind of real-time access and collaboration is not limited to human intellectual interaction but can also be used for automated processes like regression tests. Some experiences that validate this approach will be presented from the development and testing of the TEA+ E/E system, developed by Volvo Group Trucks Technology.
One of the characteristics of complex systems, like embedded systems, is the multitude of aspects that need concern during development.
The classical (minimal) PDM approach is to manage the product structure of the system, where detailed information is kept as proprietary, black box representations for each block in the structure. For established mechanical systems this is a working solution.
Unfortunately, for complex systems the product or module structure is one of the least important structure to be managed. Other more or equally important structures or viewpoints are, to mention a few:
Connectivity – interfaces between components defining responsibilities between them
Interaction – how the component interact through the interfaces in order to achieve desired functional properties. Allocation – how functionality or responsibility is allocated to the physical structure
