ALM–PLM integration: Why it matters for multi-domain engineering (Part 2 of 2)
By special arrangement with OVUM Analysts, we’re pleased to present this second of a 2-part blog series with the full content of a new whitepaper by OVUM Principal Analyst Michael Azoff on Polarion ALM and its integration with Siemens Teamcenter. At the conclusion of the series you will be able to download it a free PDF of the entire whitepaper. (Read Part 1)
The engineering background at CNHI
CNH Industrial (CNHI) is a global manufacturer of tractors, combines, excavators, wheel loaders, trucks, buses, firefighting, and civil protection vehicles. It has 64 manufacturing plants, 49 research and development centers, and a workforce of more than 69,000 people in 190 countries. CNHI’s market is typically building highly specialized vehicles in low volumes, rather than mass vehicle production. Ovum spoke with Edoardo Sivera, who runs a cross-departmental team responsible for methodologies, standards, and supporting other teams in adopting new technologies. The introduction of Polarion to CNHI is a major undertaking with the aim of improving processes.
A large amount of custom embedded software is developed for any given vehicle. This is produced by internal teams and by external partners and suppliers, with as many as 15 to 20 contributing to one vehicle. For example, a typical truck will have 20 to 30 SKUs with software engineering content: body computer, dashboard, navigation system, engine control unit, braking control unit, and so on. Each SKU can contain from 20 to 100 applications. One of the key tasks for CNHI is integrating the work items from the various suppliers and internal teams. The software programming languages used are typically C for body electronics and engine control and C++ for infotainment applications, with increasingly Java used for these applications.
Sivera’s team is responsible for the software in the SKUs, running a central point within CNHI for software development standards. The embedded software ends up in dashboard vehicle controls, instrument clusters, and displays. For example, tractors today have large displays providing a mass of information. A typical application transferred to flash memory varies from 500KB to 24MB in size.
Although the decision to adopt ALM was made by the engineers, the acceptance of the solution met with some resistance due to the clash of cultures that ALM introduces within the PLM world. To manage the traceability and the impact analysis of changes it is necessary for the engineers to create links between requirements, Matlab/Simulink/Stateflow models, and test cases. Polarion creates the links automatically and manages the traceability, but the engineers can be reluctant to take the time to do so. This is the cultural challenge: although some engineers are working enthusiastically with ALM, others are resisting the new tool. This is a continuing change management challenge that will take some years to fully unfold.
The interaction between the many external suppliers and the 20+ internal design and development centers is also complex. Some external suppliers are already Polarion users, but with those that are not there is little leverage that CNHI can apply due to the low production volumes and the reluctance of these suppliers to bear the cost of switching tools. Again, the resolution of these challenges will come with better support for plug-and-play tool interoperability standards.
CNHI has been using Polarion as its global ALM solution since 2010. Where teams are using Polarion the process of work flow has been made easier; such centers are linked together to share information using a common database. The processes used in development span waterfall, agile, and hybrid. Where waterfall is used it follows the traditional engineering V-model and the main processes are agile and V-model with an incremental lifecycle. Projects typically have three or four iterations before delivering the final product, driven by the combined software, electrical, and mechanical lifecycles. In addition, model-based design and development is the norm for all projects started at CNHI since 2012, exploiting simulation and auto code generation for speeding development and improving quality. Given the many contributing suppliers and sources of software, CNHI has developed a modular architecture for both the hardware and software.
CNHI uses Siemens Teamcenter for its PLM solution, and started working with the ALM–PLM integrated edition in July 2014, so it is still early days for the project. Only a subset of the 20–22 centers has been trying out the integration. Siemens Teamcenter has been present in CNHI since approximately 2000 and is a stable and consolidated tool within the organization, broadly used for product description, creating bills of materials, and so on. However, Teamcenter is a typical mechanical engineers’ tool, used to manage the components and the physical parts of a vehicle. It became necessary to integrate Teamcenter with Polarion and create a bridge between the software development and the other parts of engineering a vehicle.
Benefits of the ALM–PLM transformation at CNHI
The integration approach taken is to keep data at source and create live links across the tool chain: data residing in Teamcenter stays in Teamcenter and data residing in Polarion stays in Polarion. Triggers implemented at certain points in the various engineering processes initiate action across the ALM–PLM divide, in both directions. In this way it is possible to create automated workflows that take place concurrently in Teamcenter and Polarion and that cross the tool divide. For example, CNHI has spent years perfecting an environment for managing defect issues arising in product validation. When a defect is discovered it is logged and evaluated and if it has a software-related dimension it is entered into Teamcenter as a software problem. With the new integration this will automatically trigger a defect issue in Polarion.
A major aim of the ALM–PLM integration is the traceability of requirements, so that, for example, a software requirement is traceable to its implementation as embedded code in an electronic control unit. Whereas automated traceability within PLM and within ALM is possible to perform, the work to manage fully automated lifecycle traceability across the ALM and PLM divide is still ongoing, with some parts of the process requiring manual link creation. This creates a chore for engineers and meets with the heaviest resistance. However, as Teamcenter and Polarion continue to bridge the processes across the divide, traceability will improve and with it the adoption of ALM. One of the most critical areas from a quality assurance perspective is the traceability between requirements (from system to components) and testing. This is a high priority for the ALM–PLM integration project by the tool vendors.
CNHI has seen a big improvement in task or issue management. Prior to the ALM–PLM integration it was difficult to trace all activities in a project. A project typically has a long list of activities assigned to people and teams and it is now possible to know quickly the status of tasks – how many are completed, in progress, or waiting to start. For managers there is a clear view of the status of a project and this is the biggest improvement over the last year.
The most common form of writing requirements is in Microsoft Office products: Excel, PowerPoint, and Word. Fortunately Polarion has a round-trip mechanism so that a requirement in a Word document can be read and generated by Polarion. This means that CNHI suppliers can work with Office documents and Polarion can process these documents. The gap between the tools used between CNHI and its suppliers needs to be reduced for an improvement in speed to market. This is clearly a work in progress.
Conclusions
Ovum’s analysis
The engineering industries are facing a challenge in how they manage the software that is driving innovation and reducing costs, but at the same time introducing new challenges related to software quality, complexity, and security. ALM–PLM integration will become recognized as a necessity in ensuring these challenges are met and the benefits realized.
Polarion is an independent ALM vendor that has secured a special relationship with Siemens, enabling an advanced integration to be offered between Polarion ALM and Siemens’s PLM solution, Teamcenter. This integration project has recently completed the first phase of a multiphase integration road map. There are few examples of such strong ALM–PLM integration on the market and Polarion should be at the top of any Siemens Teamcenter-based manufacturer’s ALM short list. It offers unparalleled access to Siemens Teamcenter, resulting in deep ALM–PLM integration, and the comprehensive functionality available in Polarion ALM.
The ALM and PLM solutions exist within an ecosystem of design and development tools and for users to gain the optimum benefit of all these tools they ideally need to interoperate and exchange data. Therefore the industry as a whole will benefit from the creation and adoption of suitable standards. Standards organizations and industry bodies are driving the introduction of standards across the SDLC and it will take some time for these to gain adoption, but there is a need for such standards if the benefits of software-rich engineered products are to be realized in safe and secure machines.
Editor’s Note: The author of this article is Michael Azoff, Principal Analyst, Software Solutions for OVUM. Content of this article is reproduced by permission from the OVUM publication titled ALM–PLM integration: Why it matters for multi-domain engineering, which contains the following:
Copyright notice and disclaimer
The contents of this product are protected by international copyright laws, database rights and other intellectual property rights. The owner of these rights is Informa Telecoms and Media Limited, our affiliates or other third party licensors. All product and company names and logos contained within or appearing on this product are the trademarks, service marks or trading names of their respective owners, including Informa Telecoms and Media Limited. This product may not be copied, reproduced, distributed or transmitted in any form or by any means without the prior permission of Informa Telecoms and Media Limited.
Whilst reasonable efforts have been made to ensure that the information and content of this product was correct as at the date of first publication, neither Informa Telecoms and Media Limited nor any person engaged or employed by Informa Telecoms and Media Limited accepts any liability for any errors, omissions or other inaccuracies. Readers should independently verify any facts and figures as no liability can be accepted in this regard – readers assume full responsibility and risk accordingly for their use of such information and content.
Any views and/or opinions expressed in this product by individual authors or contributors are their personal views and/or opinions and do not necessarily reflect the views and/or opinions of Informa Telecoms and Media Limited.
GET THE FULL WHITEPAPER
(FREE & Free to Share)
