an overview of ap-233: the systems engineering data exchange standard based on step iso-10303

1. 2003 Annual Conference An Overview of AP-233: The Systems Engineering Data Exchange Standard based on STEP (ISO-10303)

2. 2003 Annual Conference Topics of this Discussion Why Do We Need a Standard to Exchange Systems Engineering Data? Objectives of AP-233? How does AP-233 fit into STEP? How Would We Apply It? What is the status of AP-233?

3. 2003 Annual Conference Why do we need a Standard to Exchange Systems Engineering Data?

4. 2003 Annual Conference Product Development Focus Should be on Requirements� That�s what the customer will buy That�s how you know when your done That�s how you communicate across disciplines That�s how you know you have a quality product That�s how you know what you can use from last time around � I don�t think we need to convince you that requirements are important. -that�s when you define what the customer will buy. Failure to define requirements properly means you are not actively planning to meet customer needs, which means you are �lucky� when you produce a product that the customer will buy. -that�s how you know when you have done enough work/development�otherwise you have a tendency to over do it or under do it based on how much time you have scheduled in the project -that�s how you communicate among the many disciplines involved in your product development (different disciplines use the same words to describe different things). Requirements are the only common language that ultimately matters to everyone�without them you churn and have the same meetings over and over. -that�s how you know when you have a quality product�after all the definition of quality according to crosby and juran is �conformance to requirements�. -that�s how you know what can be reused from last time around�what existing components meet this set of requirements. I don�t think we need to convince you that requirements are important. -that�s when you define what the customer will buy. Failure to define requirements properly means you are not actively planning to meet customer needs, which means you are �lucky� when you produce a product that the customer will buy. -that�s how you know when you have done enough work/development�otherwise you have a tendency to over do it or under do it based on how much time you have scheduled in the project -that�s how you communicate among the many disciplines involved in your product development (different disciplines use the same words to describe different things). Requirements are the only common language that ultimately matters to everyone�without them you churn and have the same meetings over and over. -that�s how you know when you have a quality product�after all the definition of quality according to crosby and juran is �conformance to requirements�. -that�s how you know what can be reused from last time around�what existing components meet this set of requirements.

5. 2003 Annual Conference Life Cycle Swoosh Ok, we�ve convinced you that requirements are important, but that�s not enough. Once we capture them, we need to deliver them throughout the development process so requirements can influence design decisions towards compliance�requirements everywhere. If we can influence daily design decisions we can start to �build in� customer compliance. Ok, we�ve convinced you that requirements are important, but that�s not enough. Once we capture them, we need to deliver them throughout the development process so requirements can influence design decisions towards compliance�requirements everywhere. If we can influence daily design decisions we can start to �build in� customer compliance.

6. 2003 Annual Conference Are You Playing Games with Your Customer Wants� Given their importance, it�s not uncommon for organizations to have some type of mechanism for capturing and distributing requirements�such as a document or requirements database. The problem is they are probably stuck off to the side somewhere nobody has access to or in a tool that isn�t available to everyone. The result is your probably relying on word of mouth or meetings to pass requirements among product disciplines. This is equivalent to playing the telegraph game. That�s the game where one person starts by whispering something in one person�s ear, passing it on to the next person, and so forth and when you are done, everyone laughs at the difference between what it started out as and what it became. Here is an example: (walk through game)... You are probably passing requirements among tools by reentering them or passing them along via word of mouth�which means you are playing this game only at a corporate level with--with critical information getting passed among people and organizations and losing its meaning along the way. We are after solving this problem for your organization. Given their importance, it�s not uncommon for organizations to have some type of mechanism for capturing and distributing requirements�such as a document or requirements database. The problem is they are probably stuck off to the side somewhere nobody has access to or in a tool that isn�t available to everyone. The result is your probably relying on word of mouth or meetings to pass requirements among product disciplines. This is equivalent to playing the telegraph game. That�s the game where one person starts by whispering something in one person�s ear, passing it on to the next person, and so forth and when you are done, everyone laughs at the difference between what it started out as and what it became. Here is an example: (walk through game)... You are probably passing requirements among tools by reentering them or passing them along via word of mouth�which means you are playing this game only at a corporate level with--with critical information getting passed among people and organizations and losing its meaning along the way. We are after solving this problem for your organization.

7. 2003 Annual Conference The Corp. Telegraph Game... Looking at this telegraph game in the spiral of your product development life cycle with each organization fitted into it [click] we see that marketing is supposed to understand the customer wants and translate those wants into feature specs that accurately describe those wants. [click] These are typically thrown over the wall to design who continues to translate those wants into designs that can be thrown over to the manufacturing organization [click] �with each person/organization along the way adding their interpretation of the customer wantsor recapturing the requirements in tools they use [click] �resulting in we�re building something the customer doesn�t want. Imagine the amount of time/effort that is being wasted in this miscommunication and reentry process� [click] Were developing a requirements exchange standard ISO STEP AP-233 that allows requirements to move between the various tools used throughout the product development life cycle. This allows requirements to show up throughout the process�the result is a consistent view of customer wants across the entire organization avoiding reentering or worse yet ignoring your customer wants. Looking at this telegraph game in the spiral of your product development life cycle with each organization fitted into it [click] we see that marketing is supposed to understand the customer wants and translate those wants into feature specs that accurately describe those wants. [click] These are typically thrown over the wall to design who continues to translate those wants into designs that can be thrown over to the manufacturing organization [click] �with each person/organization along the way adding their interpretation of the customer wantsor recapturing the requirements in tools they use [click] �resulting in we�re building something the customer doesn�t want. Imagine the amount of time/effort that is being wasted in this miscommunication and reentry process� [click] Were developing a requirements exchange standard ISO STEP AP-233 that allows requirements to move between the various tools used throughout the product development life cycle. This allows requirements to show up throughout the process�the result is a consistent view of customer wants across the entire organization avoiding reentering or worse yet ignoring your customer wants.

8. 2003 Annual Conference Exchanging Systems Engineering Data

9. 2003 Annual Conference System Engineering Process We can take one of these contemporary processes, here IEEE 1220, which elaborates several of the activities that occur �within� systems engineering. This indicates the interactions which occur between activities, which implies information exchange of design material taking place.We can take one of these contemporary processes, here IEEE 1220, which elaborates several of the activities that occur �within� systems engineering. This indicates the interactions which occur between activities, which implies information exchange of design material taking place.

10. 2003 Annual Conference Systems Engineering Process and SE Tools Typically any one project and/or organisation has decisions to make as to which of a number of tools are used to support these tasks, capturing design information and supporting the analysis and reporting tasks necessary to apply to that information. Inevitably, these implies exchange between tools, since often different tools are used to support different activities. Further even if a single tool can support all of these activities, there are exchanges necessary with the environments and stakeholders outside of this explicit context!Typically any one project and/or organisation has decisions to make as to which of a number of tools are used to support these tasks, capturing design information and supporting the analysis and reporting tasks necessary to apply to that information. Inevitably, these implies exchange between tools, since often different tools are used to support different activities. Further even if a single tool can support all of these activities, there are exchanges necessary with the environments and stakeholders outside of this explicit context!

11. 2003 Annual Conference Vendor Issue: # of Tool Interfaces Achieving a standards-based way of exchanging design information has the critical benefit of dramatically improving the development/maintenance cost situation for environments which need many design tools. This is the usual (N(N-1) versus 2N argument. Additionally, the establishment of standards-based design data exchange is a stepping stone on a longer path to achieve neutral design repositories where individual design tools can put information in and out of such repositories as required.Achieving a standards-based way of exchanging design information has the critical benefit of dramatically improving the development/maintenance cost situation for environments which need many design tools. This is the usual (N(N-1) versus 2N argument. Additionally, the establishment of standards-based design data exchange is a stepping stone on a longer path to achieve neutral design repositories where individual design tools can put information in and out of such repositories as required.

12. 2003 Annual Conference Currnet Data Exchange Context This slide indicates visually the interactions necessary: across the full lifecycle; across participating organisations.This slide indicates visually the interactions necessary: across the full lifecycle; across participating organisations.

13. 2003 Annual Conference From Isolation to Inter-Working A data exchange standard is a stepping stone to the ultimate objective of a design data centric (rather than design tool centric) design environment.A data exchange standard is a stepping stone to the ultimate objective of a design data centric (rather than design tool centric) design environment.

14. 2003 Annual Conference What are the Objectivesand What Does AP-233 Do?

15. 2003 Annual Conference Objectives of AP-233 Establish rigorous internationally defined semantics for System Engineering concepts to enable accurate exchange of: System Requirements System Architecture System Functionality and Behavior System Properties���� To achieve the ability to exchange information accurately between tools using dissimilar data structures and representations from simple text to multimeia to models, AP233 must define the basic concepts of System Engineering and codify their meaning and relationships more rigorously than related process standards such as EIA-632, IEEE 1220, and ISO 15288 which �only� require human understanding, that is, they rely on a more powerful processor -- a human -- on the other end of the transfer to resolve ambiguities. To achieve the goal of making AP233 widely usable, it must represent SE concepts while remaining independent of tool-specific and platform-specific formats. In addition, it must be usable across a wide variety of organizational approaches, acquirer-supplier relationships, and engineering methods. Finally, it must be elegant enough to retain the power to express an enormous variety of System Engineering information yet be simple enough to allow tool vendors to develop export-import filters at a reasonable cost and organizations to apply AP233 with a reasonable amount of training and support.To achieve the ability to exchange information accurately between tools using dissimilar data structures and representations from simple text to multimeia to models, AP233 must define the basic concepts of System Engineering and codify their meaning and relationships more rigorously than related process standards such as EIA-632, IEEE 1220, and ISO 15288 which �only� require human understanding, that is, they rely on a more powerful processor -- a human -- on the other end of the transfer to resolve ambiguities. To achieve the goal of making AP233 widely usable, it must represent SE concepts while remaining independent of tool-specific and platform-specific formats. In addition, it must be usable across a wide variety of organizational approaches, acquirer-supplier relationships, and engineering methods. Finally, it must be elegant enough to retain the power to express an enormous variety of System Engineering information yet be simple enough to allow tool vendors to develop export-import filters at a reasonable cost and organizations to apply AP233 with a reasonable amount of training and support.

16. 2003 Annual Conference AP-233: What Does it Do? Application Protocol (AP) 233, Systems Engineering Data Representation, provides a neutral format for exchange of data between Systems Engineering tools, and: Program (Project) Management Product Data Management Computer Aided Engineering (CAE or CAx) Computer Aided System Engineering (CASys) Computer Aided Software Engineering (CASE) Computer Aided Design (CAD) & Manufacturing (CAM) Engineering Analysis (Verification and Validation) For those of you who are not familiar with AP233, let me set the stage by describing briefly what AP233 is. AP233 is intended to address the problem of exchanging information between one tool and another tool within the program engineering environment that uses a suite of tools for different disciplines. Without AP233, for years we have either moved this information by building custom interfaces for each specific tool pair or we have moved the data manually by re-entering it in the other tool. What we need is the ability to move data from one tool into a format that can be read by other tools. AP233 will provide this capability by defining a precise computer-readable format for expressing System Engineering information. This will enable tools to export data in AP233 format and import data in AP233 format regardless of the tool vendor or type of tool. Exchanges will be performed either by sending files, for example, by email or FTP, or by sending transactions enabling a collaborative work environment. AP233 is being developed by the International Standardization Organization (ISO) in the Industrial Data subcommittee which has spent over 10 years developing a family of consistent engineering data standards known as STEP -- the STandard for Exchange of Product information -- also known as ISO 10303.For those of you who are not familiar with AP233, let me set the stage by describing briefly what AP233 is. AP233 is intended to address the problem of exchanging information between one tool and another tool within the program engineering environment that uses a suite of tools for different disciplines. Without AP233, for years we have either moved this information by building custom interfaces for each specific tool pair or we have moved the data manually by re-entering it in the other tool. What we need is the ability to move data from one tool into a format that can be read by other tools. AP233 will provide this capability by defining a precise computer-readable format for expressing System Engineering information. This will enable tools to export data in AP233 format and import data in AP233 format regardless of the tool vendor or type of tool. Exchanges will be performed either by sending files, for example, by email or FTP, or by sending transactions enabling a collaborative work environment. AP233 is being developed by the International Standardization Organization (ISO) in the Industrial Data subcommittee which has spent over 10 years developing a family of consistent engineering data standards known as STEP -- the STandard for Exchange of Product information -- also known as ISO 10303.

17. 2003 Annual Conference AP-233: What Does it Do? It is part of the ISO 10303 STandard for Exchange of Product information Enables File Oriented Exchange Enables Repository Oriented Exchange Enables Process and Organization Integration and Interoperability Enables a Collaborative Integrated Environment across a multiple discipline product team For those of you who are not familiar with AP233, let me set the stage by describing briefly what AP233 is. AP233 is intended to address the problem of exchanging information between one tool and another tool within the program engineering environment that uses a suite of tools for different disciplines. Without AP233, for years we have either moved this information by building custom interfaces for each specific tool pair or we have moved the data manually by re-entering it in the other tool. What we need is the ability to move data from one tool into a format that can be read by other tools. AP233 will provide this capability by defining a precise computer-readable format for expressing System Engineering information. This will enable tools to export data in AP233 format and import data in AP233 format regardless of the tool vendor or type of tool. Exchanges will be performed either by sending files, for example, by email or FTP, or by sending transactions enabling a collaborative work environment. AP233 is being developed by the International Standardization Organization (ISO) in the Industrial Data subcommittee which has spent over 10 years developing a family of consistent engineering data standards known as STEP -- the STandard for Exchange of Product information -- also known as ISO 10303.For those of you who are not familiar with AP233, let me set the stage by describing briefly what AP233 is. AP233 is intended to address the problem of exchanging information between one tool and another tool within the program engineering environment that uses a suite of tools for different disciplines. Without AP233, for years we have either moved this information by building custom interfaces for each specific tool pair or we have moved the data manually by re-entering it in the other tool. What we need is the ability to move data from one tool into a format that can be read by other tools. AP233 will provide this capability by defining a precise computer-readable format for expressing System Engineering information. This will enable tools to export data in AP233 format and import data in AP233 format regardless of the tool vendor or type of tool. Exchanges will be performed either by sending files, for example, by email or FTP, or by sending transactions enabling a collaborative work environment. AP233 is being developed by the International Standardization Organization (ISO) in the Industrial Data subcommittee which has spent over 10 years developing a family of consistent engineering data standards known as STEP -- the STandard for Exchange of Product information -- also known as ISO 10303.

18. 2003 Annual Conference What Does AP-233 Cover? Requirements: text and model-based + requirements traceability System and Subsystem views including hierarchies (BOM, CFI, FD, HW, SW) System Behaviour and Functional Architecture functional decomposition, interfaces, & allocation functional & data flows; behaviour models; finite state machines, etc. AP233 represents the System Engineering concepts that you would find in any textbook. These include the following areas which constitute major Units of Functionality in AP233: It is capable of representing any number of views of the system including partial views. It can express requirements and relationships between them. We are explicitly addressing the ability to represent requirements as models. It can model the system in functional terms providing hierarchical decomposition, detailed interface modeling, and functional allocation. Types of models being addressed include: functional and data flows diagrams, behavior models, and finite state machines including Petri nets. The physical architecture of the system can be defined as a Product Breakdown Structure down to the parts level. It also allows for reusable elements to support organizations that maintain parts libraries and product lines that span many projects and systems. Properties of system elements can be defined and expressed in engineering units such as m-k-s and English. Remember the Martian lander problem? Lockheed could have avoided the unit conversion problem with a subcontractor by using AP233 to exchange this information. AP233 supports data configuration management as systems evolve from concept to design to manufacturing to maintenance. Finally, details of graphical layout and presentation are necessary such as representing the location of the INCOSE 2000 icon on this page in the upper right corner.AP233 represents the System Engineering concepts that you would find in any textbook. These include the following areas which constitute major Units of Functionality in AP233: It is capable of representing any number of views of the system including partial views. It can express requirements and relationships between them. We are explicitly addressing the ability to represent requirements as models. It can model the system in functional terms providing hierarchical decomposition, detailed interface modeling, and functional allocation. Types of models being addressed include: functional and data flows diagrams, behavior models, and finite state machines including Petri nets. The physical architecture of the system can be defined as a Product Breakdown Structure down to the parts level. It also allows for reusable elements to support organizations that maintain parts libraries and product lines that span many projects and systems. Properties of system elements can be defined and expressed in engineering units such as m-k-s and English. Remember the Martian lander problem? Lockheed could have avoided the unit conversion problem with a subcontractor by using AP233 to exchange this information. AP233 supports data configuration management as systems evolve from concept to design to manufacturing to maintenance. Finally, details of graphical layout and presentation are necessary such as representing the location of the INCOSE 2000 icon on this page in the upper right corner.

19. 2003 Annual Conference What Does AP-233 Cover? System Physical Architecture and Interface Control component decomposition, interfaces, & allocation parts libraries & product lines System Properties, Classification and Data definition System Engineering and Program Management Model layout and presentation information AP233 represents the System Engineering concepts that you would find in any textbook. These include the following areas which constitute major Units of Functionality in AP233: It is capable of representing any number of views of the system including partial views. It can express requirements and relationships between them. We are explicitly addressing the ability to represent requirements as models. It can model the system in functional terms providing hierarchical decomposition, detailed interface modeling, and functional allocation. Types of models being addressed include: functional and data flows diagrams, behavior models, and finite state machines including Petri nets. The physical architecture of the system can be defined as a Product Breakdown Structure down to the parts level. It also allows for reusable elements to support organizations that maintain parts libraries and product lines that span many projects and systems. Properties of system elements can be defined and expressed in engineering units such as m-k-s and English. Remember the Martian lander problem? Lockheed could have avoided the unit conversion problem with a subcontractor by using AP233 to exchange this information. AP233 supports data configuration management as systems evolve from concept to design to manufacturing to maintenance. Finally, details of graphical layout and presentation are necessary such as representing the location of the INCOSE 2000 icon on this page in the upper right corner.AP233 represents the System Engineering concepts that you would find in any textbook. These include the following areas which constitute major Units of Functionality in AP233: It is capable of representing any number of views of the system including partial views. It can express requirements and relationships between them. We are explicitly addressing the ability to represent requirements as models. It can model the system in functional terms providing hierarchical decomposition, detailed interface modeling, and functional allocation. Types of models being addressed include: functional and data flows diagrams, behavior models, and finite state machines including Petri nets. The physical architecture of the system can be defined as a Product Breakdown Structure down to the parts level. It also allows for reusable elements to support organizations that maintain parts libraries and product lines that span many projects and systems. Properties of system elements can be defined and expressed in engineering units such as m-k-s and English. Remember the Martian lander problem? Lockheed could have avoided the unit conversion problem with a subcontractor by using AP233 to exchange this information. AP233 supports data configuration management as systems evolve from concept to design to manufacturing to maintenance. Finally, details of graphical layout and presentation are necessary such as representing the location of the INCOSE 2000 icon on this page in the upper right corner.

20. 2003 Annual Conference Where Do We Apply It?

21. 2003 Annual Conference Who Is Developing AP-233?

22. 2003 Annual Conference Who is developing AP-233? Development initiated by European consortium in 1995 Accepted by ISO as a New Work Item in 1997 Approved by 14 countries Now under development by ISO TC 184/SC 4 INCOSE, STEP and OMG support Standards Tech Committees, AP-233 Interest Groups Formal ISO, STEP (PDES, Eurostep, PLCS) and OMG INCOSE Models & Tools Tech Committee Model Driven System Design WG: Mike Dickerson, Jim U�ren Tools Integration & Interoperability WG: Jim Schier, John Nallon, Katherine Clinton

23. 2003 Annual Conference

24. 2003 Annual Conference AP-233 STEP European SupportSystem Engineering Data Representation & Exchange Standard

25. 2003 Annual Conference Why are We Adding Systems Engineering to Step?

26. 2003 Annual Conference Adding Systems Engineering to STEP Scope, STEP has the intention of covering the full product life cycle.Scope, STEP has the intention of covering the full product life cycle.

27. 2003 Annual Conference STEP Applied to Spacecraft Development

28. 2003 Annual Conference STEP Application Protocols +AP201: Explicit Draughting (Drafting) +AP202: Associative Draughting (Drafting) +AP203: Configuration Controlled 3D Designs of Mechanical Parts and Assemblies AP204: Mechanical Design using boundary representation AP205: Mechanical Design using Surface Representation +AP207: Sheet Metal Die Planning and Design +AP209: Composite & Metallic Analysis & Related Design +AP210: Electronic Assembly, Interconnect and Packaging Design +AP212: Electro-technical Design and Installation +AP213: Numerical Control (NC) Process Plans for Machined Parts +AP214: Core Data for Automotive Mechanical Design Processes

29. 2003 Annual Conference STEP Application Protocols AP215-218: Ship Arrangement, Moulded Forms, Piping, Structures AP220 PCA Process Planning AP221: Functional Data and their Schematic Representation for Process Plant AP222: Design to Manufacturing for Composite Structures AP223: Exchange of Design and Manufacturing Product Information for Cast Parts +AP224 Mechanical Product Definition for Process Planning Using Machining Features +AP225: Building Elements Using Explicit Shape Representation AP226: Ship Mechanical Systems +AP227: Plant Spatial Configuration AP231: Process Design and Process Specifications of Major Equipment AP232: Technical Data Packaging Core Information and Exchange AP233: Systems Engineering Data Representation

30. 2003 Annual Conference AP-233 and the STEP architecture This slide provides one view of the way AP-233 is seen to fit into the architecture of a comprehensive set of Application Protocols with STEP that cover full product data. This view was produced by the ESPRI organisation, not by SEDRES. It illustrates the cross-discipline view of AP233 and the Technical Data Packaging AP, AP-232, in contrast to the �specialist� AP�s, such as AP203, tackling different �vertical� domains, such as geometric design. This slide provides one view of the way AP-233 is seen to fit into the architecture of a comprehensive set of Application Protocols with STEP that cover full product data. This view was produced by the ESPRI organisation, not by SEDRES. It illustrates the cross-discipline view of AP233 and the Technical Data Packaging AP, AP-232, in contrast to the �specialist� AP�s, such as AP203, tackling different �vertical� domains, such as geometric design.

31. 2003 Annual Conference Who Is Supporting This?

32. 2003 Annual Conference Who is Supporting AP-233? Major design & manufacturing organisations worldwide, for instance: Aerospace Memorandum of Common Understanding and Cooperation, Dec 1993 Rolls-Royce, Pratt & Whitney, General Electric, Boeing Commercial Airplane Group, and SNECMA. Automotive Memorandum of Common Understanding and Cooperation, Feb 1993 AUDI AG, BMW AG, Chrysler Corporation, FIAT, Ford Motor Co, General Motors Corporation, Mercedez-Benz, ADAM OPEL, Porsche,Volkswagen Weight, STEP has the support of some major companies.Weight, STEP has the support of some major companies.

33. 2003 Annual Conference Who is Supporting STEP? Major organizations include: ISO, INCOSE, OMG NATO DoD, UK MoD, French MoD NASA PDES inc - predominantly US ProSTEP � Europe PLCS � Europe/US/Asia-Pacific JSTEP - Japan GOSET - France Weight, STEP has the support of some major organisations and industry backed STEP associations.Weight, STEP has the support of some major organisations and industry backed STEP associations.

34. 2003 Annual Conference AP-233 Development Plan & Status

35. 2003 Annual Conference Schedule of Deliverables STEP System Engineering Team The successful vote in 1997 represented a significant hurdle overcome along a series of stages in developing an ISO standard. This diagram illustrates these stages against the time line that AP233 is now working along. Current activities are aiming to complete a stable working draft, in preparation for ISO Committee Draft status. See the following slides for the objectives of each of these stages.The successful vote in 1997 represented a significant hurdle overcome along a series of stages in developing an ISO standard. This diagram illustrates these stages against the time line that AP233 is now working along. Current activities are aiming to complete a stable working draft, in preparation for ISO Committee Draft status. See the following slides for the objectives of each of these stages.

36. 2003 Annual Conference ISO AP-233: Future Schedule for AP 233 has been adjusted SE has bigger scope than anticipated early on More harmonization with STEP APs than planned Final Committee Draft in late 2001 Input Draft International Standard in 2002, signoff 2003 Steady progress in development & education: Strong international support Strong corporate support evidenced by SEDRES participants & INCOSE workshop participants SE Tool vendors starting to show support This slide is self-explanatory.This slide is self-explanatory.

37. 2003 Annual Conference How Can We Benefit from AP-233? Early adopters will have significant competitive advantages in process & tool improvements Immediate opportunities exist! Implement AP-233 prototype tool interfaces between any two tools most useful to your organization. Investigate how well AP-233 terminology and structure match your organization�s engineering processes. Start prompting your company and tool vendors for AP-233 support.

38. 2003 Annual Conference EDS PLM Solutions andAP-233 SLATE and AP-233 EDS PLM Solutions is heavily involved in INCOSE TCs and AP-233 June �02 implemented a SLATE AP-233 Export Utility for Requirements 4 Hours to implement, 4 hours to validate & package (8 hours) Exported system requirements to Requisite Pro and Core at INCOSE Symposium in Las Vegas June �02.

39. 2003 Annual Conference STEP, ISO, AP-233 Internet Site Links

40. 2003 Annual Conference STEP and AP-233 Websites INCOSE: www.incose.org SEDRES: www.sedres.com ISO TC184/SC4: www.iso.ch/meme/TC184SC4.html NIST: www.nist.gov/sc4 PDESinc: pdesinc.aticorp.org ProSTEP: www.prostep.de/ps_e_welcome.htm PDM Implementor�s Forum: www.pdf-if.org International STEP Centers: isc.aticorp.org

41. 2003 Annual Conference STEP and AP-233 Websites STEPml: www.stepml.org JPL: step.jpl.nasa.gov/step/step.html NASA: step.nasa.gov The NASA STEP Testbed: STEP/OMG infrastructure pilot project -- misspiggy.gsfc.nasa.gov/step/step.html The OMG Manufacturing Domain Task Force (MfgDTF): PDM Enablers, etc. -- www.omg.org/homepages/mfg

42. 2003 Annual Conference Thanks for Listening!!