This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

ALM/PLM Scenarios of Interest to GM

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

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.
    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.
  • 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.
  • S-Ten SemanticSTEP? . . 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

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
    • 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.
  • 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

Topic attachments
I Attachment Action Size Date Who Comment
jpgjpg Acceleration_Requirement_Refinement_and_Verification.jpg manage 62.4 K 14 Dec 2010 - 18:38 MikeLoeffler Acceleration Requirement Refinement and Verification
zipzip manage 1469.7 K 15 Feb 2011 - 14:37 MikeLoeffler First release of the HSUV Example model after refactoring to make it possible to show the change scenario sequence
zipzip manage 1469.7 K 15 Feb 2011 - 15:57 MikeLoeffler First release of the Step00 (Preconditions) view of the HSUV Example model after refactoring to make it possible to show the change scenario sequence
zipzip manage 1218.6 K 17 Feb 2011 - 22:00 MikeLoeffler Added Gray's annotations to diagrams and cleaned up
zipzip manage 1600.9 K 22 Feb 2011 - 16:07 MikeLoeffler Made more annotations and some corrections to the model structure
zipzip manage 1312.5 K 28 Feb 2011 - 20:58 MikeLoeffler Revised item ID's to correspond to Teamcenter
zipzip manage 3646.2 K 01 Mar 2011 - 21:32 MikeLoeffler Added some example documentation to the model containing Teamcenter screenshots, developing capability for navigable self-contained package to explain the scenario.
zipzip manage 4773.2 K 05 Apr 2011 - 19:35 MikeLoeffler Inserted new STEP and OWL files generated with Release 08 translator
zipzip manage 1446.5 K 28 Feb 2011 - 20:46 MikeLoeffler HSUV Example Story 1 Step 0.4 Postconditions
zipzip manage 3697.3 K 15 Apr 2011 - 19:55 MikeLoeffler COMPLETE Story 1 Model through the end (Step 1.4), requirement changed and design changed to comply.
zipzip manage 2405.4 K 05 Apr 2011 - 19:36 MikeLoeffler Inserted new STEP and OWL files created with Release 08 translator
zipzip manage 1399.3 K 12 Apr 2011 - 14:19 MikeLoeffler Early release of the model at Story 2, Step 2.2 level. Story 2 adds variant information.
zipzip manage 2033.8 K 30 May 2011 - 16:27 MikeLoeffler COMPLETE Story 2 Model with changed requirements for USD and EU variants
zipzip manage 1497.3 K 14 Apr 2011 - 20:06 MikeLoeffler Added new requirements for emissions derived from the new marketing region requirements
zipzip manage 1690.6 K 10 May 2011 - 15:27 MikeLoeffler Story 2 model complete through the Requirements changes, including the addition of variants and options
elsepptx HSUVExample_Story_1.pptx manage 4833.5 K 15 Apr 2011 - 19:11 MikeLoeffler COMPLETE Story 1 (Requirements Change) Step by Step Description with Pictures (stiil in process)
elsepptx HSUVExample_Story_2.pptx manage 2884.4 K 30 May 2011 - 13:22 MikeLoeffler COMPLETE Slides describing the Story 2 sequence, which adds two variants of the emissions requirement, complete through step 2.6
zipzip manage 46.4 K 26 Jan 2011 - 21:37 MikeLoeffler Should match Release 12 model
zipzip manage 220.6 K 15 Sep 2010 - 20:19 MikeLoeffler Topcased version of the HSUV Model with extra data and annotations, this will be the basis for further study
zipzip manage 3066.1 K 28 Oct 2010 - 17:42 MikeLoeffler The release adds some sequence and derivation relationships for the Emissions requirements, changed to use dependency relationships for these concepts so they are consistent across requirements and blocks
zipzip manage 2407.3 K 21 Jan 2011 - 21:07 MikeLoeffler Replaced again with more version fixes, updated STEP and OWL versions and re-uploaded Release 11 of the HSUV Model, ID's and versions synchronized with a Teamcenter instantiation of the model structure.
zipzip manage 2437.7 K 26 Jan 2011 - 21:36 MikeLoeffler Added top level product context to tie requirements and structure into
zipzip manage 516.6 K 17 Sep 2010 - 19:59 MikeLoeffler Release 2 of the HSUV Model in Topcased, this one adds most of the structure
zipzip manage 959.4 K 23 Sep 2010 - 13:42 MikeLoeffler Release 3 of the HSUV Model in Topcased, this one adds the PowerControlUnit? breakdown, and all version info is moved to properties of the requirements/blocks instead of comments
zipzip manage 1786.4 K 27 Sep 2010 - 17:26 MikeLoeffler Release 4 of the HSUV Model in Topcased, adds the decomposition of PowerControlUnit? and introduces version 2 of requirement and structures to meet it
zipzip manage 13.0 K 01 Oct 2010 - 20:05 MikeLoeffler These are latest STEP Part 21 and OWL files extracted by XSLT directly from the Topcased SysML? model, requirements, creator and created date info included, produced with STEP_OWL_XSLT_Release_1 stylesheets
zipzip manage 2114.5 K 08 Oct 2010 - 19:55 MikeLoeffler Release 5 is major rearrangement, combining the requirements, structure and use case models into one model called HSUVExample
zipzip manage 26.6 K 08 Oct 2010 - 19:52 MikeLoeffler These are latest STEP Part 21 and OWL files extracted by XSLT directly from the combined Topcased SysML? ? model, requirements, blocks, creator and created date info included, produced with STEP_OWL_XSLT_Release_2 stylesheets
zipzip manage 2224.4 K 13 Oct 2010 - 20:53 MikeLoeffler Release 6 finishes major rearrangement started in Release 5, and adds the dual fuel pump variant of the fuel tank assembly to go with the Ultra Low Emissions software and calibrations
zipzip manage 27.9 K 13 Oct 2010 - 20:51 MikeLoeffler These are latest STEP Part 21 and OWL files extracted by XSLT directly from the combined Topcased SysML? model, requirements, blocks, creator and created date info included, produced with STEP_OWL_XSLT_Release_2 stylesheets
zipzip manage 1679.4 K 14 Oct 2010 - 18:24 MikeLoeffler Release 7 cleans out redundant stuff and cleans up diagrams from Release 6
zipzip manage 2184.3 K 21 Oct 2010 - 20:21 MikeLoeffler Release 8 rearranges the calibrations and app software to be part of the subsystem assembly, and has the block structure fixed to correlate to the way that the SysML? -AP233 mapping team recommends it to be done
zipzip manage 2435.7 K 25 Oct 2010 - 21:05 MikeLoeffler Release 9 adds an example of my approach for version relationship representation (preceding/following, etc.)
zipzip manage 112.9 K 31 Aug 2010 - 19:26 MikeLoeffler First version of HSUV Requirements in STEP AP233 based OWL/RDF
elsepptx HSUV_Example_Change_Scenario.pptx manage 78.8 K 25 Jan 2011 - 17:22 MikeLoeffler HSUV Example step by step process description that is meant to match the Topcased and Teamcenter models as they exist here in their latest forms. These will be further refined and made completely self consistent as the test case is built up.
elsepptx HSUV_Example_Change_Scenario_V3.pptx manage 79.0 K 26 Jan 2011 - 21:38 MikeLoeffler Should match Release 12 model
jpgjpg HSUV_Specification.jpg manage 200.5 K 14 Dec 2010 - 18:35 MikeLoeffler HSUV Specification Requirements Diagram
pdfpdf Mechatronics_SysML_Scenarios.pdf manage 174.9 K 30 Mar 2010 - 16:06 MikeLoeffler GM Scenarios and Background
jpgjpg OSLC_Cases.jpg manage 243.1 K 10 May 2010 - 19:28 MikeLoeffler This is a SysML? Activity Diagram approximating the Details of Scenario 1 from above:
zipzip manage 10.6 K 25 May 2010 - 17:01 MikeLoeffler TOPCASED compatible SysML? Model for Collaborative Editing
jpgjpg Requirements_Derivation.jpg manage 136.5 K 14 Dec 2010 - 18:36 MikeLoeffler HSUV Requirements Derivation
zipzip manage 218.1 K 15 Sep 2010 - 12:29 MikeLoeffler Repaired version of the second release of SysML? HSUV Example in AP233 translated to OWL/RDF
zipzip manage 587.0 K 05 Apr 2011 - 19:23 MikeLoeffler Updated translation package to use id properties on the blocks for the SYSTEM entities
zipzip manage 9.2 K 01 Oct 2010 - 20:11 MikeLoeffler These are the XSLT stylesheets used to extract STEP Part 21 from the Topcased SysML? XMI, this first release handles requirements and associated metadata
zipzip manage 11.3 K 08 Oct 2010 - 19:49 MikeLoeffler These are the XSLT stylesheets used to extract STEP Part 21 from the Topcased SysML? XMI, this release adds block (structure) handling and works on single combined models
zipzip manage 11.5 K 14 Oct 2010 - 18:30 MikeLoeffler These are the XSLT stylesheets used to extract STEP Part 21 from the Topcased SysML? XMI, this release adds handling for derived requirements and assignment of requirements
zipzip manage 520.9 K 21 Oct 2010 - 20:22 MikeLoeffler Release 4 changes block mapping to correspond to the recommendation of the SysML? -AP233 mapping team
zipzip manage 1791.2 K 25 Oct 2010 - 21:06 MikeLoeffler This release adds handling to extract the version relationship stuff, it will handle sequence, derivation and hierarchy
zipzip manage 1791.3 K 28 Oct 2010 - 17:43 MikeLoeffler This release goes with Release 10 of the model, it extracts product version relationships represented as dependencies on requirements and blocks
zipzip manage 587.0 K 16 Mar 2011 - 15:29 MikeLoeffler Compatible with the model structure in the HSUVExample_AMG54556* series
Topic revision: r52 - 30 May 2011 - 16:27:51 - MikeLoeffler
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback