Automotive Design & Production is the one media brand invested in delivering your message in print, online, via email, and in-person to the right automotive industry professionals at the right time.
Issue link: https://adp.epubxp.com/i/592275
45 Granted, "lean manufacturing" method- ologies for developing physical products are similar to the "agile development" methodologies used in software develop- ment. And PLM does an excellent job at managing product-related workfows, specifcations, designs, and versions, but it falls apart doing the same for software. Software development is simply too complex for PLM. Other diferences exist. PLM focuses on physical, manufactured "parts." ALM focuses on software fles and items (e.g., requirement document, software code, a test case) and changes to those fles and items. Second, PLM is hardly browser based. ALM is, which enhances collaboration, development, test, and deployment. Says Rizzo, "It is not possible today for a user to perform a detailed 3D rendering and bill of materials with traceability links of a vehicle's transmission displayed in China from a server located in Stuttgart." Next, PLM traceability focuses on the decomposition of a complete system; that is, a part or component as it relates to a subassembly, which relates to the fnished (assembled) product. In ALM, traceability focuses on the links between fles and items, even if they exist in diferent phases. For instance, says Rizzo, "A change to a requirement may impact a line of code, or require a new test case to be developed to validate the new requirement." A problem occurs where PLM considers software a "part," but does not consider the details in the lifecycle development of that chunk of software. This is especially true in mechatronics. "Soft- ware quality issues lie at the bottom of many costly product failures and may drive a product recall. And yet product engineers with their PLM tools lack the ability to get to the bottom of software related issues," he continues. Mechatronics is forcing the need for both PLM and ALM, as well as the need to have these systems work together. The PLM vendors have taken notice. For example, one of the goals of the partnership between Siemens PLM Software and Polarion is the real-time synchronization of software, electrical, and mechanical development. The frst product as a result became available in June: version 1 of the Polarion Connector for Teamcenter, which works with Polarion ALM 2015 and Teamcenter 10.1.4. For $890, the connector permits integrated requirements management (such as the bidirectional referencing of software and product requirements), traceability at all levels (with no data duplication in either PLM or ALM), integrated software change management across both PLM and ALM, and closed- loop embedded systems and software. Benefts of this approach, explains Vera Sparre, Polarion's director of global marketing, include increased productivity "through closed-loop software and product development from inception to end-of-life"; better quality assurance through "better modeling and simulation as part of model-based systems engineering for continuous software validation"; better "cost containment" through "efective software delivery and reuse, as well as optimization of software design decisions in context"; and better "scalability due to the proven enterprise infrastructure that requires minimal organizational adjustment." The integration of PLM and ALM winds up being a more-encompassing realization of what Siemens PLM calls systems driven product development (SDPD), resulting in a variety of benefts for both manufacturers and consumers. At the very least, according to Siemens PLM, ALM users no longer have to switch to PLM to search, view, and modify data residing in Teamcenter PLM, or vice versa. Similarities Diferences Both systems are built around process and core disciplines ALM is centered on software "fles" and prescribes a process to create software applications. These applications consist of multiple item types and complex relationships between these item types, which in turn create impact trees. PLM is oriented around "parts" which form a tree structure of part-of relationships. Both systems incorporate workfow, variant management, test management, requirements, and specifcation management ALM deals in the abstract. PLM deals in the concrete. In ALM, software engineers envision, elicit, defne, implement, test, and maintain abstract functions. PLM's scope is to deliver a bill of materials to the production chain. The function of the components in PLM is the component itself. Both systems allow linking components to each other In PLM there is a "part-of" link type creating decomposition hierarchies. In ALM there are many diferent link types creating dependency hierarchies. Both systems allow linking information to components In PLM this information is pure mathematics: formulas, tolerances, diagrams, etc. In ALM the information linked to items is descriptive: textual, mock-ups, user stories, test scenarios, etc. In both environments there is a wide usage of models In PLM models follow the part-of decomposition and defne product shapes. PLM models are usually divided into diferent layers representing diferent product subsystems: electrical layout, braking subsystem, transmission, interior, etc. In ALM a model follows the functional decomposition by means of diagrams like entity- relationship or object-oriented.