PlmScenariosGm < Main

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.

TWiki>

Main Web>PlmHome>PlmScenarios>PlmScenariosGm (30 May 2011, MikeLoeffler) (raw view)

---+ ALM/PLM Scenarios of Interest to GM
---++ Latest HSUV Example Model and XSLT for STEP Data Extraction (others are available in the table below)

   * [[%ATTACHURL%/HSUVExample_AMG54556_001_Release_05_Step00.zip][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
   * [[%ATTACHURL%/HSUVExample_AMG54556_002_Release_02_Step04.zip][HSUVExample_AMG54556_002_Release_02_Step04.zip]]: Same as above
   * [[%ATTACHURL%/HSUVExample_AMG54556_002_Release_01_Step14.zip][HSUVExample_AMG54556_002_Release_01_Step14.zip]]: COMPLETE Story 1 Model through the end (Step 1.4), requirement changed and design changed to comply.
   * [[%ATTACHURL%/HSUVExample_AMG54556_003_Release_03_Step26.zip][HSUVExample_AMG54556_003_Release_03_Step26.zip]]: Story 2 model complete through the Requirements changes, including the addition of variants and options
   * [[%ATTACHURL%/HSUVExample_AMG54556_003_Release_01_Step35.zip][HSUVExample_AMG54556_003_Release_01_Step35.zip]]: COMPLETE Story 2 Model with changed requirements for US and EU variants
   * [[%ATTACHURL%/HSUVExample_Story_1.pptx][HSUVExample_Story_1.pptx]]: COMPLETE Story 1 (Requirements Change) Step by Step Description with Pictures (updated to match revisions of above)
   * [[%ATTACHURL%/HSUVExample_Story_2.pptx][HSUVExample_Story_2.pptx]]: COMPLETE Story 2 sequence, which adds two variants of the emissions requirement
   * [[%ATTACHURL%/STEP_OWL_XSLT_Release_08.zip][STEP_OWL_XSLT_Release_08.zip]]: Updated translation package to use id properties on the blocks for the SYSTEM entities
---
   * [[%ATTACHURL%/HSUV_Example_Change_Scenario_V3.pptx][HSUV_Example_Change_Scenario_V3.pptx]]: Should match Release 12 model (final release of combined model and scenario)
   * [[%ATTACHURL%/HSUVModel_Release_12.zip][HSUVModel_Release_12.zip]]: Added top level product context to tie requirements and structure into (final release of combined model)
   * [[%ATTACHURL%/HSUVExample_Teamcenter_PLMXML.zip][HSUVExample_Teamcenter_PLMXML.zip]]: Should match Release 12 model (final release of combined model)
   * [[%ATTACHURL%/HSUVExample_AMG54556_001_Release_04_Step00_With_Example_Docos.zip][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.
   * [[%ATTACHURL%/STEP_OWL_XSLT_Release_6.zip][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
   * [[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-ap233:mapping_between_sysml_and_ap233][SysML and AP233 Mapping Activity]] is in the sweet spot for the ALM/PLM Integration. [[http://www.omgsysml.org][OMG SysML]] is a tie in to Requirements Management and Model Driven Systems Design, using the UML 2.X Infrastructure as the basis. [[http://www.ap233.org][AP233]] is one of the [[http://www.tc184-sc4.org/SC4_Open/Projects/documentation.cfm?CFID=1374304&CFTOKEN=60453139&LID=1104&state=C&BB=1][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.
   * [[http://www.omg.org/spec/PLM/][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 [[http://www.prostep.org/en/project-groups/maintenance.html][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 [[http://www.omg.org/spec/PLM/2.0/schema/InformationalModel.xsd][InformationalModel]] section provides an XML schema that might be directly applicable to the representation of ALM/PLM information. The [[http://www.prostep.org][ProSTEP]] organization provides an open source reference server and client implementation of the PLM Services 2.0 specifications [[http://www.prostep.org/de/standards-amp-infos/omg-plm-services.html][here]].
   * [[http://www.omg.org/technology/documents/formal/product_data_management_enablers.htm][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.
   * [[http://www.autosar.org/][AUTOSAR]] and [[http://www.atesst.org/scripts/home/publigen/content/templates/show.asp?P=125&L=EN&ITEMID=7][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.<br />([[http://www.sciencedirect.com/science/article/B6TYR-4P3DY2N-2/2/03485a11e77bcbd112fd279451c32d5f][http://www.sciencedirect.com/science/article/B6TYR-4P3DY2N-2/2/03485a11e77bcbd112fd279451c32d5f]])<br />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][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][http://www.nist.gov/manuscript-publication-search.cfm?pub_id=901544]]
   * S-Ten SemanticSTEP. [[http://www.s-ten.net/][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 [[http://www.omg.org/spec/PLM/2.0/PDF/][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 [[http://www.omgsysml.org/An-Overview-of-SysML-for-Products-&-Systems-Dev-Balmelli-ibm-061002.pdf][ 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 [[http://www.omgsysml.org/INCOSE-OMGSysML-Tutorial-Final-090901.pdf][OMG SysML Tutorial]]. This example has been cited and extended in a related paper, [[http://www.omgsysml.org/Building_SE-SW_Bridges%20.pdf][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.

-- Main.MikeLoeffler - 03 Mar 2010
   * [[%ATTACHURL%/Mechatronics_SysML_Scenarios.pdf][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

Attachments

Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
jpg	Acceleration_Requirement_Refinement_and_Verification.jpg	manage	62.4 K	14 Dec 2010 - 18:38	MikeLoeffler	Acceleration Requirement Refinement and Verification
zip	HSUVExample_AMG54556_001_Release_01.zip	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
zip	HSUVExample_AMG54556_001_Release_01_Step00.zip	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
zip	HSUVExample_AMG54556_001_Release_02_Step00.zip	manage	1218.6 K	17 Feb 2011 - 22:00	MikeLoeffler	Added Gray's annotations to diagrams and cleaned up
zip	HSUVExample_AMG54556_001_Release_03_Step00.zip	manage	1600.9 K	22 Feb 2011 - 16:07	MikeLoeffler	Made more annotations and some corrections to the model structure
zip	HSUVExample_AMG54556_001_Release_04_Step00.zip	manage	1312.5 K	28 Feb 2011 - 20:58	MikeLoeffler	Revised item ID's to correspond to Teamcenter
zip	HSUVExample_AMG54556_001_Release_04_Step00_With_Example_Docos.zip	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.
zip	HSUVExample_AMG54556_001_Release_05_Step00.zip	manage	4773.2 K	05 Apr 2011 - 19:35	MikeLoeffler	Inserted new STEP and OWL files generated with Release 08 translator
zip	HSUVExample_AMG54556_002_Release_01_Step04.zip	manage	1446.5 K	28 Feb 2011 - 20:46	MikeLoeffler	HSUV Example Story 1 Step 0.4 Postconditions
zip	HSUVExample_AMG54556_002_Release_01_Step14.zip	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.
zip	HSUVExample_AMG54556_002_Release_02_Step04.zip	manage	2405.4 K	05 Apr 2011 - 19:36	MikeLoeffler	Inserted new STEP and OWL files created with Release 08 translator
zip	HSUVExample_AMG54556_003_Release_01_Step22.zip	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.
zip	HSUVExample_AMG54556_003_Release_01_Step35.zip	manage	2033.8 K	30 May 2011 - 16:27	MikeLoeffler	COMPLETE Story 2 Model with changed requirements for USD and EU variants
zip	HSUVExample_AMG54556_003_Release_02_Step20.zip	manage	1497.3 K	14 Apr 2011 - 20:06	MikeLoeffler	Added new requirements for emissions derived from the new marketing region requirements
zip	HSUVExample_AMG54556_003_Release_03_Step26.zip	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
pptx	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)
pptx	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
zip	HSUVExample_Teamcenter_PLMXML.zip	manage	46.4 K	26 Jan 2011 - 21:37	MikeLoeffler	Should match Release 12 model
zip	HSUVModel_Release_1.zip	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
zip	HSUVModel_Release_10.zip	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
zip	HSUVModel_Release_11.zip	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.
zip	HSUVModel_Release_12.zip	manage	2437.7 K	26 Jan 2011 - 21:36	MikeLoeffler	Added top level product context to tie requirements and structure into
zip	HSUVModel_Release_2.zip	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
zip	HSUVModel_Release_3.zip	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
zip	HSUVModel_Release_4.zip	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
zip	HSUVModel_Release_4_STEP_and_OWL_Extracts.zip	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
zip	HSUVModel_Release_5.zip	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
zip	HSUVModel_Release_5_STEP_and_OWL_Extracts.zip	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
zip	HSUVModel_Release_6.zip	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
zip	HSUVModel_Release_6_STEP_and_OWL_Extracts.zip	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
zip	HSUVModel_Release_7.zip	manage	1679.4 K	14 Oct 2010 - 18:24	MikeLoeffler	Release 7 cleans out redundant stuff and cleans up diagrams from Release 6
zip	HSUVModel_Release_8.zip	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
zip	HSUVModel_Release_9.zip	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.)
zip	HSUV_AP233_OWL_V1.1.zip	manage	112.9 K	31 Aug 2010 - 19:26	MikeLoeffler	First version of HSUV Requirements in STEP AP233 based OWL/RDF
pptx	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.
pptx	HSUV_Example_Change_Scenario_V3.pptx	manage	79.0 K	26 Jan 2011 - 21:38	MikeLoeffler	Should match Release 12 model
jpg	HSUV_Specification.jpg	manage	200.5 K	14 Dec 2010 - 18:35	MikeLoeffler	HSUV Specification Requirements Diagram
pdf	Mechatronics_SysML_Scenarios.pdf	manage	174.9 K	30 Mar 2010 - 16:06	MikeLoeffler	GM Scenarios and Background
jpg	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:
zip	OSLC_Cases.zip	manage	10.6 K	25 May 2010 - 17:01	MikeLoeffler	TOPCASED compatible SysML? Model for Collaborative Editing
jpg	Requirements_Derivation.jpg	manage	136.5 K	14 Dec 2010 - 18:36	MikeLoeffler	HSUV Requirements Derivation
zip	STEP_OWL_Release_2.zip	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
zip	STEP_OWL_XSLT_Release_08.zip	manage	587.0 K	05 Apr 2011 - 19:23	MikeLoeffler	Updated translation package to use id properties on the blocks for the SYSTEM entities
zip	STEP_OWL_XSLT_Release_1.zip	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
zip	STEP_OWL_XSLT_Release_2.zip	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
zip	STEP_OWL_XSLT_Release_3.zip	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
zip	STEP_OWL_XSLT_Release_4.zip	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
zip	STEP_OWL_XSLT_Release_5.zip	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
zip	STEP_OWL_XSLT_Release_6.zip	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
zip	STEP_OWL_XSLT_Release_7.zip	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

Main

Webs
Main
Sandbox
TWiki

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