ALM–PLM integration: Why it matters for multi-domain engineering (Part 1 of 2)
By special arrangement with the OVUM analyst research firm, we’re pleased to present 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.
Management summary
Introduction
Software has become the defining differentiator in engineering manufacturing in multiple ways. For the manufacturer its engineers often have a choice to construct a requirement using mechanical, electronic, or software technology. Increasingly software wins as the choice that offers speed of creation, degree of flexibility/ease of change, and lowest cost. For consumers software adds value by providing choice and flexibility to configure custom preferences. A good example is how consumers faced with choosing a car include in their criteria the infotainment system and advanced driver assistance.
The trend with software-driven systems is for increasing software content; for example, high-end vehicles now contain 100 million lines of source code. The flip side to the benefits of software is that it contains bugs. The world of enterprise IT has been familiar with software quality issues since its earliest days and application lifecycle management (ALM) solutions grew as part of the drive to manage software development lifecycle (SDLC) complexity and quality. Now we see that as the sheer volume of software in engineered products increases it is necessary to manage the challenge of software quality and complexity in engineering.
Ovum has seen the highest rate of ALM system adoption in mechatronics industries that also embrace PLM. The highest potential for growth of ALM is in the PLM world. Although open-source tools dominate at the core developer level and tend to change frequently with development fashions and rapid advances in technology, the management tools need to be stable and long lasting. This applies to both enterprise IT and engineering IT, and ALM in engineering is still a relatively new concept.
In addition, the biggest disruptor in software development has been the emergence of agile and DevOps practices, which is also impacting software in engineering. A new generation of ALM solutions has grown to manage the new processes as well as continue to support legacy processes (waterfall and hybrids). Whether in enterprise IT or in engineering, ALM systems must support a range of patterns of work, from V-model-based processes to agile iterations and continuous engineering delivery.
Another significant technology disrupter to emerge is the Internet of Things (IoT). When combined with cloud services this gives the feedback loop in continuous engineering delivery a new significance, because products can be updated and serviced in situ, over the air. There are also implications for mining big data analytics in maintenance repair and operations and remote servicing, leading to improved customer service response and more.
Software engineering is taking center stage in building advanced manufactured products and ALM systems are essential to manage the ensuing software complexity and software quality challenges. With ALM systems increasingly found in PLM environments there is the need to connect these systems together to optimize the production and reduce delivery time.
Siemens is a leading PLM provider with its Teamcenter solution and has an investment partnership in Polarion. The two companies worked closely together to integrate Teamcenter with Polarion ALM, offering a significant step forward in addressing the need for ALM–PLM integration. Polarion also has a strategy for integrations with the other main PLM solutions on the market, but the Siemens Teamcenter integration has been developed by Polarion with the full support of Siemens.
The topic of ALM–PLM integration is a key one in software-driven engineering today, addressing the management of software quality and complexity, often with safety critical aspects. There is a need for lifecycle traceability and this is driving the adoption of ALM across industries. To understand the advantages of integrating Polarion ALM with Siemens Teamcenter, the market needs to learn about the benefits that can be realized in ALM–PLM integration.
The need for ALM–PLM integration
Software adds benefits and complexity
The old days of mechanical engineering dominating manufacturing are being transformed by new technologies: electronic controls, computers, and software have taken over. In particular, software content in advanced engineered products is growing massively because it offers greater flexibility in design, ease of change, increasing product innovation, and greater re-use with product variants.
The current technology waves will accelerate this change. Cloud services and IoT are having far- reaching consequences for a range of industries, including mechatronics, automotive, and aerospace and defense. These waves are accelerating opportunities for servicing and upgrading products over the air. A wealth of monitoring data is also being captured and fed back over the air, leading to acceleration in product design and development as engineers reduce the cycle time in trialing new features and continuously improve products and production processes. Complexity arises with the fast pace of change as new technologies are introduced and new product development and introduction becomes more challenging.
Co-design processes between electrical-electronic and mechanical engineering are well established in Siemens Teamcenter. These design processes cannot exist separately – at certain points they must interact. For example, the effect of constraints (e.g., match dimensional constraints and mount points, achieve density and complexity requirements in smaller spaces) in one process will have an impact on the other. During simulation and analysis it is desirable to co-simulate all the engineering elements. More design and development work has been moved into virtual environments to speed the cycle time and improve quality.
The rise of software content in products only increases the complexity. For example, a major Chinese conglomerate has 2,000 software releases per year, entailing 50,000 builds per day, 100 million test cases run per day, 480,000 code-reviews per year, and 170,000 systems integrations per year. However, most engineering companies do not build and test every single component from a single location. Instead a complex supply chain of partners builds and tests various components of a product. This can result in thousands of release cycles for all the different components. The impact of a change in cycle frequency of one component will have a ripple effect to other components and the overall product update cycle.
Many different product models from different manufacturers share the same component with some variant, so that the change and variant management become extremely complex. In addition, variants due to regional requirements further complicate an already challenging situation.
- The risks of not using an ALM system to manage software development are manifold: Managers have no insight into project progress.
- Software quality problems such as trends related to modules and their bug counts are discovered late.
- Lack of traceability results in delays in gathering information, slowing development.
- Lack of collaboration and sharing of knowledge can result in duplicated work and
knowledge walking out the door when developers move jobs. - Without auditable systems there is no proper governance of safety critical components.
This list goes on and on. Once the size of the software development reaches a certain level, such as multiple teams and suppliers, the use of ALM solutions becomes essential.
ALM–PLM integration with Polarion
Multi-domain engineering with the addition of software requires a closed loop between hardware and software design and development, with continuous engineering delivery. Across all the domain processes there needs to be a global orchestration of traceability, verification, and validation; security enforcement (authentication, authorization, and export limitation); and monitoring of quality and cost, leading to predictable quality and reducing wastage, such as duplicate efforts and infrastructure.
For example a requirement arrives from the PLM solution into Polarion ALM and a closed-loop change management is performed with the PLM solution and updated as the requirement is fulfilled in the ALM process. Once a binary is ready to be built, Polarion’s release and build management solution can be implemented, possibly with the addition of third-party build accelerators, to complete the continuous engineering delivery.
Polarion requirements can read a wide range of document types, including models written in UML, SysML, Matlab, and Simulink documents. The ALM–PLM integration benefit is that every document that can be displayed in Teamcenter can be exposed in Polarion. Only information is transferred between the ALM and PLM solutions, so that data always stays at source. Teamcenter is driven through requirements, and in particular change in requirements, with nearly all new requirements based on a change of existing requirements. Requirements are central to how Teamcenter manages PLM and therefore the integration with Polarion ALM requirements management is a critical part of the overall ALM–PLM integration.
Test management is the next stage in ALM–PLM integration
Requirements and testing follow closely in ALM. Testing has two main purposes: it verifies that requirements are being met in the developed code (doing the right thing) and it validates that the code is working correctly (doing the thing right). In the engineering V-model shown in Figure 2 requirements represent the left arm and testing the right arm. Please note that this model can be applied in both waterfall and iterative processes.
Integrated ALM systems are designed to manage the connection between these arms and will integrate with the various testing tools, both automated and manual, that perform the actual testing. To facilitate governance such as compliance and auditing the ALM and PLM solutions need to interface and be able to interrogate the systems for the status of testing.To deal with this integration challenge, Polarion QA and xUnit Integration offer test information integration out of the box, supporting third-generation test automation software that deploys xUnit or jUnit testing frameworks, and via APIs and out-of-the-box integration with the leading software testing tool solutions.
Variant management
Product lines today contain more variants than ever before. Manufacturers can release new variants on a monthly basis with the very latest feature enhancements. Software makes it possible to multiply the number of choices available on the market to match the precise needs of customers. From a logistics view point this creates a management challenge and variant management is growing in importance in engineering ALM.
Manufacturers have grappled with the design complexities of multiple variants by designing for variants from the start, creating modular, component architectures. Keeping track of these variants is best done using a dedicated tool such as Polarion Variants. Variants allow manufacturers to satisfy the long-tail needs of a diverse set of customers while achieving the customization within budget. ALM and variant management allow manufacturers to achieve such ambitions.
As manufacturers gain more experience in using software in their products and the amount of software in products consequently increases, the need for variant management as a specialist discipline in requirements engineering will grow. This discipline also ties in well with product line engineering; as a combination they will lead to creation of software factories in the near future.
The multiple lifecycles in ALM
The familiar ALM concept has been seen mainly as SDLC focused, but there are other lifecycles within ALM. For example, testing practitioners have been using a dedicated lifecycle for managing test case generation, test execution and results analysis, and more. In addition, security practitioners have honed a software security development lifecycle based on best practices in baking-in security throughout the SDLC.
Ovum has introduced the Software X Lifecycle concept to highlight the multiple lifecycles that run concurrently in software development. Figure 2 shows how project governance, development, testing, and security apply during software development. The x-axis does not represent a process, but rather phases of the lifecycle. The figure should therefore not be read as a strict timeline, but as a correlation between disciplines and lifecycle phases. It is applicable to any chosen development methodology or process.
Next in the series: Case study: CNH Industrial
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 WHITEPAPER
(FREE & Free to Share)
