ALM/PLM Scenarios of Interest to GM

Latest HSUV Example Model and XSLT for STEP Data Extraction (others are available in the table below)

• HSUVExample_AMG54556_001_Release_05_Step00.zip: Slightly revised Topcased, STEP and Teamcenter models to match more exactly, added Work Request to the STEP model, and enhanced HTML docos will be included from here on
• HSUVExample_AMG54556_002_Release_02_Step04.zip: Same as above
• HSUVExample_AMG54556_002_Release_01_Step14.zip: COMPLETE Story 1 Model through the end (Step 1.4), requirement changed and design changed to comply.
• HSUVExample_AMG54556_003_Release_03_Step26.zip: Story 2 model complete through the Requirements changes, including the addition of variants and options
• HSUVExample_AMG54556_003_Release_01_Step35.zip: COMPLETE Story 2 Model with changed requirements for US and EU variants
• HSUVExample_Story_1.pptx: COMPLETE Story 1 (Requirements Change) Step by Step Description with Pictures (updated to match revisions of above)
• HSUVExample_Story_2.pptx: COMPLETE Story 2 sequence, which adds two variants of the emissions requirement
• STEP_OWL_XSLT_Release_08.zip: Updated translation package to use id properties on the blocks for the SYSTEM entities

• HSUV_Example_Change_Scenario_V3.pptx: Should match Release 12 model (final release of combined model and scenario)
• HSUVModel_Release_12.zip: Added top level product context to tie requirements and structure into (final release of combined model)
• HSUVExample_Teamcenter_PLMXML.zip: Should match Release 12 model (final release of combined model)
• HSUVExample_AMG54556_001_Release_04_Step00_With_Example_Docos.zip: Added some example documentation to the model containing Teamcenter screenshots, developing capability for navigable self-contained package to explain the scenario.
• STEP_OWL_XSLT_Release_6.zip: This release goes with Release 10+ of the combined model, it extracts product version relationships represented as dependencies on requirements and blocks

Key Existing or Emerging Standards to Refer to for Input

• SysML and AP233 Mapping Activity is in the sweet spot for the ALM/PLM Integration. OMG SysML is a tie in to Requirements Management and Model Driven Systems Design, using the UML 2.X Infrastructure as the basis. AP233 is one of the STEP (ISO 10303) standards series specifically dealing with Systems Engineering. STEP has a solid PDM/PLM model under it, defined to span all of the key areas of Product Description. Even though the STEP standards are primarily intended to define data interchange representations, they are very useful to unambiguously define product description concepts that can be used in other settings. STEP PDM model concepts form the foundation for PLM products from a number of vendors.
• OMG PLM Services is a specification defining the services that a PLM system must support. The definition of the services is tilted toward a SOAP implementation but the core concepts are all applicable in the ALM/PLM integration realm. According to ProSTEP (the main organization behind the development of this standard), a number of PLM system vendors support various levels of these services in their products. The InformationalModel section provides an XML schema that might be directly applicable to the representation of ALM/PLM information. The ProSTEP organization provides an open source reference server and client implementation of the PLM Services 2.0 specifications here.
• OMG PDM Enablers is an earlier specification that defines the most key services that a Product Data Management system would be expected to provide. This specifcation was last active in 2000, it was left behind due in part to its coupling to CORBA, but the concepts and service definitions are still very relevant to ALM/PLM integration. PDM Enablers are aligned with STEP, so PDM concepts in the AP's (STEP Application Protocols, i.e. AP233, AP214, AP212, AP210, AP203, etc.) are identical or equivalent to the PDM Enablers.
• AUTOSAR and EAST-ADL2 are automotive systems architecure related standards that give the reader an appreciation for some of the key ALM-PLM interaction issues that are important to the automotive OEM community. The underlying data models and modeling approaches are focused more directly on the embedded software development arena (thus more closely related to ALM), but because the entire automobile is the end product these concepts must be connected to the PLM.

Related Reference Works of Interest

• Sudarsan Rachuri, Eswaran Subrahmanian, Abdelaziz Bouras, Steven J. Fenves, Sebti Foufou, Ram D. Sriram, Information sharing and exchange in the context of product lifecycle management: Role of standards, Computer-Aided Design, Volume 40, Issue 7, Current State and Future of Product Data Technologies (PDT), July 2008, Pages 789-800, ISSN 0010-4485, DOI: 10.1016/j.cad.2007.06.012.
  (http://www.sciencedirect.com/science/article/B6TYR-4P3DY2N-2/2/03485a11e77bcbd112fd279451c32d5f)
  Keywords: Product life cycle; PLM systems; Interoperability; Data exchange; Open standards
• Fiorentini, X., Rachuri, S., Ray, S., and Sriram, R. D. 2009. Towards a method for harmonizing information standards. In Proceedings of the Fifth Annual IEEE international Conference on Automation Science and Engineering (Bangalore, India, August 22 - 25, 2009). IEEE Press, Piscataway, NJ, 466-471. http://www.nist.gov/customcf/get_pdf.cfm?pub_id=903057
• Krima, S.; Barbau, R.; Fiorentini, X.; Sudarsan, R.; Sriram, R. D.; OntoSTEP? : OWL-DL Ontology for STEP, May 04, 2009, NIST Interagency/Internal Report (NISTIR) - 7561, Keywords: STEP; standards; semantics; ontology; OWL-DL; EXPRESS. http://www.nist.gov/manuscript-publication-search.cfm?pub_id=901544
• S-Ten SemanticSTEP? . http://www.s-ten.net/ . 2009.

Generic Scenarios (Typically Harvested from Existing Standards or Tutorials)

PLM Services Use Cases

Most of the detailed scenarios in the PLM Services 2.0 specification (link points to the PDF form) are directly applicable. These scenarios are written from the viewpoint of a PLM only world, but they can be easily extended to include ALM concepts and the related artifacts. Here is a list of the scenarios by name (the numbers are directly from the PLM Services 2.0 document for convenience of reference):

• 7.2.1 Export of assembly data

The most interesting use cases for ALM-PLM integrations are probably "7.2.20 Browsing of Abstract Product Structures", "7.2.21 Browsing of Alternative Solutions within an Abstract Product Structure", "7.2.22 Retrieve Configuration Data within an Abstract Product Structure", and all of the query related and ECM related ones. Cases "7.2.9 Download meta data including structures" and "7.2.15 Upload meta data including structures" might easily be extended to include ALM related meta data.

Note: A number of these use cases are directly related to Change Management (referred to in PLM Services as ECM, or Engineering Change Management) operations.

Note2: The concepts in the PLM Services are generally reused from the STEP Application Protocols, most are from AP214 but are defined as common core concepts that are reused in many others including AP210, AP212 and AP233.

Rain Sensing Wiper Example

An excellent paper on SysML? by Laurent Balmelli of IBM Research entitled An Overview of the Systems Modeling Language for Products and Systems Development includes an interesting model based design of a rain sensing windshield wiper system. This example would form the basis for a set of cases that exercises the PLM related aspects of this approach. Some key cases might be:

• Make a change to the requirements of the rain sensing wiper to make it capable of infinitely adjustable wiping speed (the base design only requires three discrete selectable speeds). Provide proper effectivity that allows the two designs to coexist for one overlapping model year of production. Add tests that verify the new requirements have been met, and tie them into all of the artifacts to track which tests must be performed on which artifacts.
• Support three variants of wiping systems in a single vehicle line, optionally available by customer order. One would be plain manual on-off control only, one would be manual infinitely variable wiping speed, and one would be the rain sensing version. All artifacts including Requirements, Behavioral models, hardware designs, software designs and any calibrations would be tracked through their lifecycles to support effectivity so that they can be managed through production and into customer service. Now suppose an issue is found in the field in the second production year, and all of the rain sensing systems of a certain version must be recalled and reprogrammed in dealer service. Modify tests and re-verify proper operation as necessary to close out the issue and the related change.
• Process a change request that stems from a need to add a higher power wiping motor for a new vehicle design. This higher power motor also has different speed and mechanical characteristics that reflect back into the software and calibrations, forcing rain sensing algorithm changes to start and stop the motor between wipes in a different way. Reflect that same set of changes into all of the other variants as appropriate. Modify any tests to reflect the requirements changes, rerun needed tests and properly close out the change request, making sure that any interested party can follow the progression of the change through to verification.
• Demonstrate the ability to treat the wiper subsystem as a reusable architectural component that will be applied in many different vehicle platforms. Instantiate the subsystem with three optional operating modes in a vehicle platform at a specific released revision of the subsystem architecture, ona a specific vehicle platform release model year. Instantiate the subsystem in only two optional configurations (manual infinitely variable and automatic only) on a different vehicle platform at a different effective point (later model year). Change the behavior of the rain sensing variant, ripple that change through both instantiations and verify the change works correctly, including re-running required verification tests.

The Distiller Tutorial With a Twist

One of the well defined tutorial examples in the SysML? literature is the Distiller example, in the official OMG SysML Tutorial. This example has been cited and extended in a related paper, Building Bridges Between Systems and Software with SysML and UML. The extension of adding a controller to the distiller system would be a good PLM-ALM test case. Assume that version 1.0 is the distiller without the controller, version 2.0 is with the controller, and version 3.0 adds a new type of forced air condenser. Make all three variants available at the same time, holding proper effectivity so that the parts (hardware, software and calibrations) that are shared can be traced back to their requirements correctly in all three contexts. Imagine an issue is raised in use that forces a requirements change in the controller based systems, boiler timing behavior changes that create a software change. The change can only be applied to variants without the special forced air condenser. All of them have to be serviced in the field. Change or define new tests to verify the change is correct and trace to close out the change. You get the idea...

GM Specific Scenarios

The attached PDF details a set of key scenarios that are representative of the Mechatronics area in GM. These scenarios are focused primarily on the system level of the design process, they were originally intended to detail how we intend to use SysML? models, so the detailed variant and effectivity support is omitted for clarity.

-- MikeLoeffler - 03 Mar 2010

• Mechatronics_SysML_Scenarios.pdf: GM Scenarios and Background

Details of Scenario 1, Systems Engineer Reacts to Changed Requirements

• Marketing user (change requestor) opens change request tool (probably connected to enterprise PLM repository) and creates a change request to change the (already released) requirement that defines behavior of the optional power window feature on 2012 Ultra platform to add automatic open and close on all six windows. Existing required behavior is automatic open only on driver window. The requirements at this level are likely in the PLM repository.
• Systems Engineer (SE) receives notification of the change request by email, including a link to the change request.
• SE opens the change request by clicking the link in the email, this opens a (thin or rich client) portal into the enterprise PLM system that shows many aspects of the data for the Ultra platform
• SE clicks the link in the change request that points to the requirement, opening the requirement in a SysML? Requirements Diagram editing tool
• SE creates new working revision of the Ultra platform requirements context so the requirement can be changed, the new revision opens in the requirements editing tool
• SE locates an existing generic power window feature implementation in a related architecture that matches the change requestor's needs by searching for existing requirements using the requirements editing client or related query tool
• IFF EXISTS:
  • SE compares the new implementation with the existing one, specifically looking at differences between requirements decompositions (spanning PLM and ALM), models (probably in ALM only), hardware designs (probably in PLM only) and software source code (in ALM) plus calibrations (probably in PLM)
  • SE adds the new requirement and implementation to the change request as the solution
  • SE swaps out the old implementation and replaces it with the new one in the working revision of the context
  • SE fixes any loose ends left when the new implementation was swapped in, the loose ends (potentially in both PLM and ALM) are added to the CR as solutions
• ELSE:
  • SE traces all links from the existing requirement to determine what decomposed requirements (spanning PLM and ALM), behavior models (probably in ALM only) and physical implementations (hardware in PLM, software and/or calibrations in ALM and PLM) are impacted by the change
  • SE adds all effected items to the change request by linking them
  • SE modifies each of the impacted items in the context, either swapping it out with another existing one that fits the need, or creating a new one
  • As the SE is making changes the working context is being updated as edits are saved, thus allowing interested collaborators to view and comment in real time
  • Any further detailed design changes that the SE identifies cause a detailed CR to the appropriate subject matter expert (recursively), with attached links to the specific items that need to be changed. These changes must be closed out before the complete design can be finished.
  • As each edited sub-requirement, model and physical design is finished, it is reviewed and approved for release. After all sub-elements are released the next higher assembly is updated with the new released revision if necessary.
• ENDIFF:
• SE submits the revised working context for review and approvals
• After all validations and reviews are signed off the new context is automatically moved to released state, becoming mainstream design intent, with some effectivity statement (effective immediately, effective as of a certain date, a certain build event or lot, etc.)
• Release of revisions automatically closes out the change request