An Overview of AP233 STEP’s Systems Engineering Standard October 20, 2003 Jim U’Ren AP233 Working Group Chair NASA / JPL.

An Overview of AP233 STEP’s Systems Engineering Standard October 20, Jim U’Ren AP233 Working Group Chair NASA / JPL

What is AP233 a STEP-based* data exchange standard targeted to support the needs of the systems engineering community, Parallels emerging standards in MCAD, ECAD, engineering analysis, PDM and product development domains. Provides neutral data models to exchange and integrate information between systems engineering tools * STEP – ISO (STandard for the Exchange of Product information

SEDRES Project consisted of European aerospace companies
The SEDRES Project: The Roots of AP233 (Systems Engineering Representation and Exchange Standardization) SEDRES Project consisted of European aerospace companies Aerospatiale, Alenia, British Aerospace (now BAE Systems), DASA (now DaimlerChrysler), SAAB Joint projects Gripen Eurofighter (EF2000) Project focused on specific SE data exchanges SEDRES initiated NWI in TC184/SC4 in 1998 to provide a means of publishing its work Demonstrated that STEP could be used to exchange systems engineering information During the early 1990’s, in the context of a number of joint projects, and prompted by the need to improve the systems engineering process, the companies identified design data exchange as a fertile topic for joint research work. In addition some companies had previous done limited prototyping of neutral data exchange, or were actively pursuing such approaches in other domains, such as structural design activities. These discussions led to the formulation of the SEDRES project proposal to the Framework IV funding round of the European Commission. The following slides elaborate on a number of the business issues that provide elements of the business case to supporting developments towards neutral data exchange.

Primary Driver: Reduction in Tool Interfaces
i-LOGIX STATEMATE ISI Matrix/X CAYENNE TEAMWORK SES WORKBENCH BAe CORE VERILOG SAO+ AERO LABSYS AONIX StP NEUTRAL DATA EXCHANGE FORMAT i-LOGIX STATEMATE ISI Matrix/X CAYENNE TEAMWORK SES WORKBENCH BAe CORE VERILOG SAO+ AERO LABSYS AONIX StP 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.

Current Approach of AP233 Work
Modularization Avoids lengthy gestation of large AP efforts Allows frequent, sequential deliveries Provides on going evolutionary development environment Active Development Team Bi-weekly Telecons Web-based repository to collect, secure and publish work-in-progress Public website Collaboration with existing Industry groups INCOSE - International Council on Systems Engineering OMG - Object Management Group / SE Working Group

Organizational Structure PDM Security Rules Requirements
Planned AP233 Module Sets Analysis Interfaces Scheduling Cost Models Organizational Structure PDM Security Rules Requirements Structural Models Behavioral Models Validation and Verification Data Representation Risk Analysis AP233 Module Sets The following identifies and describes the Module Sets for AP233, the STEP Systems Engineering Project. Requirements - a data model that describes requirements as text strings with traceability, allocation, weighting and risk identified with each requirement [Text-based Requirements ( TBR ) ] and that describes requirements as structured and quantified formalisms that maybe decomposed from text-based requirements; can include tables, spreadsheets, graphs, charts, pictures and equations [ Property-based Requirements (PBR) ]. Structural Models - a data model that describes how a system is built; defines the static relationships among the subsystems, components, or parts that actually constitute the system; describes what is designed, built and maintained; contains specifications for design, manufacture, and maintenance and information about actual manufactured parts and their verification and maintenance. Behavioral Models - a data model that describes how a system performs; includes functions, inputs, outputs and control operators which define the ordering of functions; the model describes Functional Flow Block Diagrams, Finite State Machines, Causal Chain, Data Flow Diagrams and Sequence Diagrams. Validation and Verification Model - a data model that describes the plan, infrastructure and status of validation and verification processes. Allocation Model - a data model that describes structures necessary to allocate requirements, schedule, costs, risks and other functions associated with a body of work. Risk Analysis - a data model that identifies risk(s), describes their status, specifies relationships, likelihood, consequence, impact approach strategy and contingencies. [ may collaborate/reuse PLCS Risk Model ] Cost Models - a data model that describes direct, indirect, fixed, variable, material, administrative, finance, and contingency costs; provides linkage to system product structure(s) Data Representation - "a consistent set of “presentation mechanisms” and “advanced schematics product model definition”, which is designed to present the computer sensible model data (defined in representation model space) onto a human understandable schematic diagram (presentation space), conforming to conventional and/or future draughting standards" [ from Intelligent Sematics PWI RDD ] [ may include features from AP221 and AP212 ] Scheduling - a data model that identifies activities, dependencies, durations and milestones associated with products described in the WBS; includes WorkFlow Diagrams, Network Schedules, Gantt Charts and Resource Leveling. [ work with PLCS ] Work Breakdown Structure - a data model that represents the structure used to represent the pieces of work necessary to complete a project. [ work with PLCS ] PDM - a data model that extends the STEP PDM Schema and PDM Modules to electro-mechanical, system engineering, product life-cycle and other non-physical domains. [ work with PLCS and PDM ] Security - a data model that describes project, organization, country and user defined security levels as well as user authentication and intellectual property. [ work with PLCS and PDM ] Organizational Structure - a data model that provides relationships, functional roles, skill qualification and documentation that defines an organizational structure. [ work with PLCS ] AP Interface Models - a data model that describes the interfaces between domain specific data models such as mechanical, electronic, structural analysis, thermal analysis, manufacturing, etc. [ work with other STEP AP groups ]

STEP in Spacecraft Development
This slide provides high level information about how STEP and other standards can be applied to the engineering domains that are part of the spacecraft development process. STEP in Spacecraft Development How the family of STEP Data Standards can be applied to Spacecraft Development Cabling & Wire Harness Standard: AP212 Status: Prototyped / In production Software MentorGraphics Orgs: Daimler-Chrysler, GM, Ford, ABB, ProSTEP, Bosch, Rockwell, Siemens Fluid Dynamics Standard: AP 237 Status: In Development Software - TBD Orgs: Boeing, AiAA, NASA/Ames) Propulsion Standard: STEP-PRP Status: In Development Software: TBD Orgs: ESA, EADS ElectroMechanical Assembly Standard: AP210 Status: Prototyped Software: Mentor Graphics, Eagle, Theorem Solutions, LKSoft, Zuken Orgs: Rockwell, Boeing, NASA, GaTech, CPES, ATI Software Engineering Standard::UML Status: In Production Industry-wide, a STEP AP233 interface to UML is In Development Software: Rational Rose, All-Together, Argo, Rhapsody Orgs: Lockheed, NASA, I-Logix, Optics Standard: NODIF Status: In Development Software - TBD Orgs: Minolta, Olympus, ORA Mechanical Engineering Standard: AP203 Ed. 1 & 2, AP214 Status: In Production Software Pro-E, Cadds, SolidWorks, AutoCad, IDEAS, Catia, Unigraphics, Alibre, and others Orgs: Industry-wide in aerospace and automotive industries (Europe & US) Systems Engineering Standard: AP233 / STEP-NRF Status: In development / Prototyped Software: Core, Doors, MatLab, MS-Excel, RTM, Slate, Statemate, System Arch, TeamWork Orgs: BAE SYSTEMS, EADS, NASA, CNES, Boeing, Lockheed, Raytheon, Vitech Structural Analysis Standard: AP209 Status: In Production Software: MSC Patran, Thermal Desktop Orgs: Lockheed Martin, Airbus, Boeing, NASA-Langely Thermal Radiation Analysis Standard: STEP-TAS Status: In Production Software: Thermal Desktop, Thermica, ESARAD, TRASYS Orgs: ESA/ESTEC, NASA (JPL & Langely) PDM Standard: STEP PDM Schema/AP232 Status: In Production Software: MetaPhase, Windchill, Insync, Matrix, Share-a-Space, STEP Book, STEP-Tools Inc. Orgs: Lockheed Martin, EADS, BAE SYSTEMS, Raytheon, NASA. Boeing, Eurostep De-emphasized boxes indicate data models that are IN DEVELOPMENT. Machining Standard:: STEP-NC/AP224, AP 238, and AP2xx (process plan) Status:: In Development / Prototyped Software:: Gibbs, STEP-Tools, CAMsoft Orgs: Honeywell, Boeing, GM, NASA-JPL Inspection (Off-line) Standard: AP219 Status: In Development Software: Technomatics, Brown, eSharp Orgs: NIST, DMIS, Boeing, Chrysler, AIAG Life-Cycle Management Standard: PLCS / AP 239 Status: In Development Software: PTC, LSC, AEI, Bonn Orgs: BAE SYSTEMS, Boeing, Eurostep, NATO, UK MoD JAU SLIDE_STEP-in-Spacecraft-Development-Ver12d.ppt

AP-233 and the STEP architecture
Mechanical and assembly design : AP203 Structural Analysis : AP209 Thermal Analysis : STEP-TAS Results of Analysis, Test & Operation Campaigns : STEP-NRF Space Technical Data Package : (AP232) Documentation Propulsion : STEP-PRP Mass & inertia Budgets (subset of AP214) Optical Analysis : NODIF ... System Engineering : AP233 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.

Tools used in testing AP233 Requirements Exchanges
Eurostep AP233 Demonstrator Tool Telelogics DOORS Rational RequisitePro EDS SLATE Vitech CORE LKSoft STEP Book NIST Expresso Eurostep SAS MS Word MS Excel Poseidon UML

Requirements Initially Developed in DOORS
Telelogics DOORS is one of the more popular requirements development and management tools. This is often where the requirements process starts but often later in the process, requirements may need to be shared with other groups using other tools - - this is what STEP AP233 is intended to address.

Export from DOORS to AP233 Requirements Format
Under contract to UK Ministry of Defence, Ian Bailey at Eurostep developed a prototype DOORS to AP233 Requirements Export Tool in the first quarter of 2003.

Requirements in AP233 Demonstrator Tool
Under contract to NASA/JPL, Ian Bailey of Eurostep developed a simple AP233 Demonstrator tool that allowed the AP233 Team to create sample data to exercise the Requirements data model.

Requirements imported in Poseidon UML
Using the XMI interface in Poseidon UML, requirements generated by common text-based requirements tools can be import into a UML environment with relationships between requirements represented graphically.

Requirements imported from AP233 into Vitech CORE
Using the API developed by Ian Bailey, tool interfaces can be easily adapted as was the case with Vitech CORE in which an AP233 import interface was quickly generated in under 4 hours.

Export from EDS Slate to AP233 Requirements Format
Again using the AP233 Requirements API, an export interface was generated by EDS staff after a brief conversation and the forwarding of some electronic documentation.

AP233 Requirements Part 21 file (ARM based)
Generated by Eurostep Demonstrator Tool ISO ; HEADER; FILE_DESCRIPTION (('Ian Bailey'), '2;1'); FILE_NAME ('C:\\Program Files\\Eurostep\\AP233 Demonstrator\\Elevator.stp', ' T14:02:48', (''), ('Ian Bailey'), 'ATBX V1.0 - AP233_PBR_ALPHA1 Toolbox Version 1.0 ( )', 'ATBX V1.0', 'C:\\Program Files\\Eurostep\\AP233 Demonstrator\\Elevator.stp.log'); FILE_SCHEMA (('AP233_PBR_ALPHA1')); ENDSEC; DATA; #1 = PRODUCT_CATEGORY ('requirement', 'requirement', 'a required property or functionality'); #2 = PRODUCT_CATEGORY ('system', 'system', 'An assembly of interacting, active components or elements forming a whole'); #3 = VIEW_DEFINITION_CONTEXT ('Systems Engineering View', $, 'System Design Stage'); #4 = REPRESENTATION_CONTEXT ('SysEng', 'Systems Engineering'); #8 = PRODUCT_CATEGORY_ASSIGNMENT (#2, (#5)); #12 = PRODUCT_CATEGORY_ASSIGNMENT (#1, (#9)); #36 = PRODUCT_CATEGORY_ASSIGNMENT (#1, (#33)); #46 = PRODUCT_CATEGORY_ASSIGNMENT (#1, (#43)); #56 = PRODUCT_CATEGORY_ASSIGNMENT (#1, (#53)); #70 = PRODUCT_CATEGORY_ASSIGNMENT (#1, (#67)); #79 = PRODUCT_CATEGORY_ASSIGNMENT (#1, (#76)); #90 = PRODUCT_CATEGORY_ASSIGNMENT (#1, (#87)); #135 = SYSTEM_DESIGN ((#3), #134, '', 'MP1v1.0view1', #3, 'MP1v1.0view1', .F.); #134 = SYSTEM_VERSION ('1.0', 'version 1.0 of MP1', #133); #133 = SYSTEM ('Description for Maintenance panel', 'MP1', 'Maintenance panel'); #140 = SYSTEM_DESIGN ((#3), #139, '', 'DT1v1.0view1', #3, 'DT1v1.0view1', .F.); #139 = SYSTEM_VERSION ('1.0', 'version 1.0 of DT1', #138); #138 = SYSTEM ('Description for Diagnostic tool', 'DT1', 'Diagnostic tool'); #161 = PRODUCT_CATEGORY_ASSIGNMENT (#2, (#158)); #142 = SYSTEM_ASSEMBLY_RELATIONSHIP ($, 'Diagnostic tool', #140, #125, 'System Assembly', $, $, $); #137 = SYSTEM_ASSEMBLY_RELATIONSHIP ($, 'Maintenance panel', #135, #125, 'System Assembly', $, $, $); #9 = REQUIREMENT ('High reliability', 'R1', 'Reliabiity'); #33 = REQUIREMENT ('Lift 200 people', 'R2', 'Lift capability'); #43 = REQUIREMENT ('Maximum number of passengers', 'R3', 'Maximum passenger load'); #53 = REQUIREMENT ('Maximum weight', 'R4', 'Maximum weight'); #67 = REQUIREMENT ('Speed requirements', 'R5', 'Speed'); #5 = SYSTEM ('A state-of-the-art elevator', 'EV1', 'Elevator'); #6 = SYSTEM_VERSION ('1.0', 'version 1.0 of EV1', #5); #7 = SYSTEM_DESIGN ((#3), #6, '', 'EV1v1.0view1', #3, 'EV1v1.0view1', .F.);

Where do we go from here? continue to pursue sponsorship
with US agencies and organizations with European organizations continue collaboration between OMG SE DSIG, INCOSE MDSD and STEP AP233 teams extend areas of collaborative work through the PDES Inc consortium

[ Backup Slides ]

AP233 Module Sets Requirements - a data model that describes requirements as text strings with traceability, allocation, weighting and risk identified with each requirement [Text-based Requirements ( TBR ) ] and that describes requirements as structured and quantified formalisms that maybe decomposed from text-based requirements; can include tables, spreadsheets, graphs, charts, pictures and equations [ Property-based Requirements (PBR) ]. Structural Models - a data model that describes how a system is built; defines the static relationships among the subsystems, components, or parts that actually constitute the system; describes what is designed, built and maintained; contains specifications for design, manufacture, and maintenance and information about actual manufactured parts and their verification and maintenance

AP233 Module Sets (cont.) Behavioral Models - a data model that describes how a system performs; includes functions, inputs, outputs and control operators which define the ordering of functions; the model describes Functional Flow Block Diagrams, Finite State Machines, Causal Chain, Data Flow Diagrams and Sequence Diagrams Data Representation - "a consistent set of “presentation mechanisms” and “advanced schematics product model definition”, which is designed to present the computer sensible model data (defined in representation model space) onto a human understandable schematic diagram (presentation space), conforming to conventional and/or future draughting standards" [work with AP212 and Intelligent Sematics PWI RDD ]

AP233 Module Sets (cont.) Risk Analysis - a data model that identifies risk(s), describes their status, specifies relationships, likelihood, consequence, impact approach strategy and contingencies [work with PLCS] Cost Models - a data model that describes direct, indirect, fixed, variable, material, administrative, finance, and contingency costs; provides linkage to system product structure(s) [work with PLCS] Scheduling - a data model that identifies activities, dependencies, durations and milestones associated with products described in the WBS; includes WorkFlow Diagrams, Network Schedules, Gantt Charts and Resource Leveling. [ work with PLCS ]

AP233 Module Sets (cont.) Work Breakdown Structure - a data model that represents the structure used to represent the pieces of work necessary to complete a project. [ work with PLCS ] PDM - a data model that extends the STEP PDM Schema and PDM Modules to electro-mechanical, system engineering, product life-cycle and other non-physical domains. [ work with PLCS and PDM ] Security - a data model that describes project, organization, country and user defined security levels as well as user authentication and intellectual property. [ work with PLCS and PDM ]

AP233 Module Sets (cont.) Organizational Structure - a data model that provides relationships, functional roles, skill qualification and documentation that defines an organizational structure. [ work with PLCS ] Validation and Verification Model - a data model that describes the plan, infrastructure and status of validation and verification processes Allocation Model - a data model that describes structures necessary to allocate requirements, schedule, costs, risks and other functions associated with a body of work AP Interface Models - a data model that describes the interfaces between domain specific data models such as mechanical, electronic, structural analysis, thermal analysis, manufacturing, etc. [ work with other STEP AP groups ]

SYSTEM ENGINEERING PROCESS (this example from IEEE1220)
Customer's Requirements System Analysis Requirements analysis Requirements trade studies Requirements Baseline validation Functional analysis Functional trade studies Functional Verification 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. Synthesis Design trade studies Physical Verification Sub-System specifications Control

The situation… Data Exchanges in context
Development life-cycle phases Fundamental Data exchanges Conception Pre-system definition System Creation Sub-System Fabrication, Assembly & Integration Test & Evaluation System-level Design Subsystem-level Design Customer Prime Contractor / Partners Sub-contractor / Suppliers This slide indicates visually the interactions necessary: across the full lifecycle; across participating organisations.

SE Process and SE Tools Requirements analysis Functional Analysis
Synthesis Physical verification RDD 100 SLATE Workbench StP CORE Foresight Teamwork Statemate Modarch OPNET Modsim III ELSIR Modline BONES DOORS 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!

From isolation to inter-working
The Past The Future tool A tool B tool A tool B 1 checks x,y,z 2 3 checker/ 4 A data exchange standard is a stepping stone to the ultimate objective of a design data centric (rather than design tool centric) design environment. viewer views a,b,c The consequences: Reduced benefits from each tool; Costs migrating to new tools/versions; Lack of an ‘integrated’ design dataset; Compromised success of partnerships The benefits: Reduced costs to transfer & check data (1, 3); Better achieve a coherent design (3, 4); Facilitate Integrated Product Development (1, 3, 4); Facilitate documentation/ design data management (2, 4)

Requirements for a system engineering exchange standard
Shall be compliant with SE processes Support for primary, support & organisational processes From requirement elicitation to V&V Consistent with concepts of SEMP Through life cycle support Shall provide a tool independent representation Shall be compatible with industrial organisation Shall be implementable / adoptable by vendors Lead to a consequential reduction in number / variety of design tool interfaces This summarised the primary requirements for a systems engineering data exchange standard. It has to be supportive of the systems engineering process, in other words it has to ‘do the job’. It is essential that it is not seen as a tool-specific or even domain-specific standard. It must be, in approach, architecture and implementation, a standard which is compatible with existing user organisations and their evolving infrastructure and tool integration policies. It must be seen to implementable, both technically, and commercially. And the bottom line is: the adoption of neutral standard-based exchange technology within an organisation must provide a net benefit to the support for the systems engineering activity, for instance, in reducing the number and variety of data exchange interfaces that would otherwise be required.

Requirements: Process compatibility
This pictorial view of lifecycle processes provides a contextual view for any systems engineering data exchange standard. Although the focus of such a standard may be rooted in a subset of such processes, for instance the primary process ‘development’, there are inevitably many interactions with the support and organisational processes with which systems engineering interacts. For instance, one may categorise verification and validation activities as ‘support processes’, but these are fundamental to the systems engineering discipline.

Requirements: Process - view points
Requirement point of view Functional structure point of view Physical structure & allocation point of view Configuration and traceability point of view Project & data management point of view Focussing on the primary systems engineering processes, this lists a number of data views that reflect SE processes and which must be accommodated. The following slides deal with each of these areas in more detail.

Requirements: Process - Requirements
Requirements, categories and structure System context & operational modes System environment description Validation & verification information Implementation verification Requirement trade study information Links to: maturity, design phases, project control, project organisation, documentation support

Requirements: Process - Functionality
Functional elements and child-parent hierarchy Requirement allocation Function inputs and function outputs Data description Behaviour description possible modelling paradigms: state machines, time lines, structured text, logic tables, mathematical, analytical.. Links to: maturity, design phases, project control, project organisation, documentation support

Requirements: Process - Physical structure
Component description Subsystem hierarchy definition Data links / Physical interface definition Information interface definition Performance allocation Function allocation Support for validation, verification, traceability Links to: maturity, design phases, project control, project organisation, documentation support

Requirements: Process - Configuration and traceability
Item identification and version control Analysis iteration control with link to version Traceability management (upward / backward) Justification traceability Security management Link to full product management (consistency between real product and architectures) Trade-off & Justification support Exchange control

Requirements: Process - Project & data management
Design process Support for work breakdown structure Support for a flexible process representation Partner organisation, stakeholders Design product packaging Work allocation

Requirements: Tool independence
Shall provide a tool independent representation ==> Neutral format data exchanges Neutral modelling paradigms Flexible item representation and description Extendibility Long term design-data storage Compatibility with several technology platforms Upward compatibility with new enabling technologies (distributed environments, distributed repositories…) Backward compatibility with simple exchange techniques This slide elaborates on the requirement for tool independence in a systems engineering data exchange standard. Neutral format data exchanges can be achieved by use of techniques such as ‘flat files’ and public standards such as SQL, SDAI and CORBA. Neutral modelling paradigms underlie many design tool notations, for instance, finite state machine modelling or functional modelling.

Requirements: Organisation
Shall be compatible with industrial organisations ==> Compatibility with industrial adopted technologies for data sharing & exchange Support for organisation description and work allocation User oriented / Usable Supports both high / low data volumes; ‘deltas’ Supports data exchange management Compatibility with other techniques used in industrial domains (CAD systems…) Extensible - evolving processes / data types

Requirements: Vendor acceptance
Shall be implementable / adoptable by vendors ==> Shown to be implementable Feasible to support (effort / cost / ROI) Tool neutral / vendor independent Based on mature data exchange technology Widely supported by tools & consultancy Widely supported by tool market users

Interface development process
Exchange standard Encoding formats SE Tool STEP Interface Process model (AAM) Information model (ARM) File + + Reusable parts (STEP Libraries IR, AIC, Modules..) Database Exchange standard (Application Protocol- AP) Is a standard for exchanging information within an application domain. Application Activity Model (AAM) Is a process model that describes the context for an exchange in an application domain. Application Reference Model (ARM) Is an information model that describes the data involved in an exchange in terms understandable by practitioners in the application domain. Reusable parts - Integrated Resources etc. (IR) Are a set of common components that can be used across a number of Applications Protocols to facilitate interoperability between related APs. Application Interpreted Model (AIM) Is an information model that describes the data involved in an exchange of product data in terms of common components. STEP provides a number of descriptive parts (meta-meta languages) for describing an AP (IDEF0, EXPRESS PART 11). Encoding formats Define the method for encoding the exchanged data. Information model (AIM) STEP Tools

Example design encoding (Part 21)
Pilot Displays pilot inputs Handle Head Down Display display attributes Avionics Systems A Part 21 encoding represents the design in a neutral format using th semantics of the Application Protocol (information model). Each entity instance in the design maps to a record in the encoding. Each record is identified as being of a particular type. Each record has a reference number. The attributes are encoded in the order they appear in the EXPRESS definition. Missing attributes are encoded as ‘$’. Attribute values are either actual values or references to other instances. DATA; #1000= INTERNAL(‘Handle Head Down Display’, $, (#1004, #1005), (#1006), ‘Calculate display attributes from Pilot selections and system inputs’); #1001= EXTERNAL(‘Pilot’, ‘Aircraft pilot or navigator’, (), (#1004)); #1002= EXTERNAL(‘Avionics Systems’, $, (), (#1005)); #1003=EXTERNAL(‘Displays’, ‘Cockpit displays’, (#1006), ()); #1004=FLOW(‘pilot inputs’); #1005=FLOW(‘system inputs’); #1006=FLOW(‘display attributes’); END_DATA; system inputs

AP233 Basic Philosophy & design principles
Focussed on semantic level information Graphics Unit of Functionality (UoF) is the exception Aspects of data model driven from principles Distinction between Instances and Definition Concept to support ‘re-use’ Aspects driven by ease of model evolution Relationship entities Support of templates for textual descriptions Model not tool-specific Additional guidelines for the model development are listed here. Primarily the work was focussed at the semantic level of information that systems engineers work with, rather than focus on trying to exchange the information directly in the form with which they work work (which can be done via document exchange anyway). Some of the concepts to be supported in the data model had a wide impact on the very structure of the data model. For instance, the notion of design re-use, where similar elements are repeated within the design in different contexts. An example would be a specification which contains two functions, control-left- engine, control-right-engine, but with the elaboration (definition) of these two functions identical. The aim was to support this concept explicitly, so concepts of instance and definition appear across several of the UoF’s. A different category of impact on the structure of the data model comes from the STEP modelling style, which encourages relationship entities, rather than direct relationship constructs, to capture relationships. Arguably this is to make the data models more flexible to subsequent development. Finally, the intention was that the data model was not intended to be tool specific, although many of the concepts supported will be recognisably related to many systems engineering tool notations.

Related to Requirement elicitation phase
Requirement UoF (1) Related to Requirement elicitation phase Defines several kind of requirements Functional requirements Constraints Physical requirements Operational requirements Other categories can be added from ECSS 10A EIA632... The Requirements unit of functionality covers textual statements about what a system must comply with, be they functional, architectural, operational aspects or system properties (safety or legislative requirements, performance, cost, etc.). The Capability/2 requirement model is limited in the sense it only accommodates textual requirements. Support for more advanced formats within the data model was consciously avoided to keep the information model size within reasonable bounds.

Supports operational scenario definition
Requirement UoF (2) Supports operational scenario definition Supports Derived requirements & composition relationship Defines the link between external entities and the system to be engineered Externals / functional context Concept of Traceability matrices support To functional breakdown structure To physical breakdown structure Requirements may be grouped into arbitrary categories or requirement groups. There is also support for representing derived and alternate requirements and the establishment of traceability from requirements onto functional and behaviour elements of the model. The unit contains entities for representing the system under specification and its operational modes.

Not linked to a particular engineering methodology
Functional UoF (1) Not linked to a particular engineering methodology SART style RDD style In-house... 2 Behaviour When ? Functions The functional UoF is about capturing what a system is intended to do, in the sense of activities (functions) to be performed. There is a strong interrelationship between the Functional UoF (capturing functions and information) and the Behavioural UoF, which is more focussed on when activities occur and functions are to be performed. 3 How ? 1 Data What ?

Supports the functional breakdown structure
Functional UoF (2) Supports the functional breakdown structure Functions, instance & definition Hierarchical relationships Flows Flow groups Stores Data description Data structure Data types Links to Behavioural model Causal chain, Finite state machine, synchronous The functional analysis unit of functionality contains entities for representing the functional architecture of a system. More specifically there is support for representing the functional context of the system, the functional hierarchy, functional interaction (flows), variables and data types. There are tools supporting many variants of functional analysis on the market. The challenge in creating the functional architecture model was to create a framework supporting the basic features of functional modelling in a way acceptable to all tools. Care has been taken to create an unambiguous model for functional decomposition. The interface of each functional element is defined through entities called flow ports. The flow of a parameter to a function (in to or out from the function) is recorded in flow ports, thus providing a clear guidance on how the function shall be used. The flow port concept is not in use explicitly by all systems engineering tools but was found very useful for defining the interface of a function.

Finite state machines (State chart style)
Behaviour UoF Finite state machines (State chart style) State, instance & definition State hierarchies Transition Action on transition Events Control of functions Causal chains for safety critical systems Synchronous model (Clock driven behaviour) The Behaviour area of the model extends the Functional Unit of Functionality to embrace detailed timing, sequencing and event-based behaviour of an emerging product. The Functional model of Capability/1 includes only the concept of functions, a functional hierarchy, and of interactions between functions. In practice, there are alternative modelling paradigms that are used to cover product behaviour. There are three paradigms included in Capability/2. Firstly, there are finite state machine concepts, such as are embodied in tools such as Statemate. Secondly, there is a procedural or functional chain approach, such as that embodied in tools such as BAe CORE; Thirdly, there is a synchronous behavioural model, frequently encountered in safety-critical real-time embedded systems architectures, such as those found on aircraft.

Component definition and breakdown structure
Physical UoF Component definition and breakdown structure Product Breakdown Structure (PBS) Bill of Materials (BOM) Physical path description Functional/physical mapping Function <=> Physical component Flows <=> Physical links This UoF supports the representation of the components that comprise a system. Furthermore, it supports the ability to allocate functions in the functional breakdown structure onto a component. A component has no specific links to a technology but rather represents a processing or functional unit. Therefore, it may represent a human being performing a task as well as a computer that would perform some complex calculation. The benefit of a physical model is that a systems engineer may assess several possible realisations of a system, initiate work load simulations and other activities to validate the correctness of the specification. In the same way that components host functions which are linked by flows, the latter are hosted by physical links. Again, these physical links are not technology dependent but are assigned performances so that overall system performance simulations can be initiated. In terms of system engineering activities this is tightly linked to trade-off studies and load balance between components and physical links.

Is this the most appropriate approach?
Graphics UoF Objective: ensure (where applicable) that designs on receiving tool can bear ‘similarity’ in layout to original Visual Elements Nodes, links that appear on SE diagrams Association to semantic elements Graphics points (nodes, links, link path) for diagram layout Is this the most appropriate approach? The Capabilty/2 data model includes support for visual presentation of designs (the UoF Graphics). This component enables the graphical representation that a designer has used in a source tool, such as a data flow diagram or a state transition diagram, to be reproduced on the destination tool. Although this component does not, of itself, communicate any semantic aspects of a design, the communication of diagram layout information appears to be crucial aspect when one inspects how designers may subsequently communicate about a design, especially when they are working in a distributed design situation.

System configuration management UoF (1)
Configuration Management Item & Item Id Traceability matrices support From requirements through to physical components Documentation support (‘Package’) Support for version control release / approval versions variants workspace revision The System Configuration Management UoF in Capability/2 include concepts associated with configuration management or (more correctly) product data management. The model distinguishes between design model items and process items. Design model items represent the information that forms the emerging design (such as requirements information or functional hierarchies). Process items capture information about, or related to, the design process. The UoF supports traceability from requirements to elements of the emerging design in later stages of the design process. It enables multiple elements to be grouped into ‘packages’. The CM UoF involves issues such as: item identification, authorship, versioning, and item maturity (life cycle).

System configuration management UoF (2)
Support for justification and maturity indices Relationships to process work breakdown, activities & products Support for industrial schema “Who does what and where” Project Company Id Person Id Convergence with STEP Product Data Mgmt (PDM) Schema The process areas of the System Configuration Management UoF enables design items to be related to the activities within that process and to work packages. The model has been developed to align with the emerging common PDM schema being developed concurrently with the STEP community, in so far as has been possible. Product data management is a challenging area, in part because it is rich in concepts and interrelationships. Also in practice all design tools cover this scope to a greater or lesser degree, and design tools are increasingly used in conjunction with dedicated products data management tools, such as SQL’s PCMS or Dassault Systeme’s Product Manager.

STEP Interface usage w.r.t SE Tools
Semantic mapping Neutral data File Database Tool API Part 21 File Database “SDAI” Part 22 Raw Data A STEP interface bridges the gap between design tool data in a design tool proprietary format and the exchanged data held in a neutral format. This is not simply a conversion of data between two different formats. There is a semantic mapping as well between the design tool and the Application Protocol which reflects the way a particular design tool is used in the Systems Engineering process, eg. If a data flow notation is used to represent a functional hierarchy then a particular data flow instance in the design tool may map to different entities in the Application Protocol dependent on its relationship to other data flow instances in the design: the top level data flow will map to the system functional context intermediate level data flows will map to composite function definitions bottom level data flows will map to leaf function definitions. The interface needs to be able to access the data in both the design tool and the exchange files, and implement a semantic mapping between the two. Interface development may be supported by a STEP tool using information models, data formats and semantic mapping information as inputs SE Tool Data Format Neutral Data Format STEP Tool Information models Semantic mapping

Test & Evaluation: ‘the bottom line’
Actual measurements of limited exchanges capture how time spent Simple analysis indicates projected times Note several activities currently due to prototype technology: Produce Part21 file.. Manage & transfer.. Prepare for import ..are likely to go to zero in industrial implementation The above diagram shows a saving in time using the SEDRES concept over an equivalent manual process. The prototype nature of the interfaces introduced an overhead in the exchange process that would be reduced in production versions. Some of the exchange time requires zero effort from the user. Most of the import time involves the user becoming familiar with the design after it has been imported, which is a value adding activity. The transfers were performed with designs containing about five diagrams plus associated data dictionary entries (process, data and state descriptions). The projected values were interpreted by observers not involved in the interface developments. We feel that in practice most of these values would be lower still.

An Overview of AP233 STEP’s Systems Engineering Standard October 20, 2003 Jim U’Ren AP233 Working Group Chair NASA / JPL.

Similar presentations

Presentation on theme: "An Overview of AP233 STEP’s Systems Engineering Standard October 20, 2003 Jim U’Ren AP233 Working Group Chair NASA / JPL."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

An Overview of AP233 STEP’s Systems Engineering Standard October 20, 2003 Jim U’Ren AP233 Working Group Chair NASA / JPL.

Similar presentations

Presentation on theme: "An Overview of AP233 STEP’s Systems Engineering Standard October 20, 2003 Jim U’Ren AP233 Working Group Chair NASA / JPL."— Presentation transcript:

Similar presentations

About project

Feedback