AECMA PREN 9300-004-2005 Aerospace series LOTAR LOng Term Archiving and Retrieval of digital technical product documentation such as 3D CAD and PDM data Part 004 Description Method.pdf

《AECMA PREN 9300-004-2005 Aerospace series LOTAR LOng Term Archiving and Retrieval of digital technical product documentation such as 3D CAD and PDM data Part 004 Description Method.pdf》由会员分享，可在线阅读，更多相关《AECMA PREN 9300-004-2005 Aerospace series LOTAR LOng Term Archiving and Retrieval of digital technical product documentation such as 3D CAD and PDM data Part 004 Description Method.pdf（14页珍藏版）》请在麦多课文档分享上搜索。

1、ASD STANDARD NORME ASD ASD NORM prEN 9300-004 Edition P 1 October 2005 PUBLISHED BY THE AEROSPACE AND DEFENSE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATION Gulledelle 94 - B-1200 Brussels - Tel. + 32 2 775 8126 - Fax. + 32 2 775 8111 - www.asd-stan.orgICS: Descriptors: ENGLISH VERSION Aerospace

2、 series LOTAR LOng Term Archiving and Retrieval of digital technical product documentation such as 3D, CAD and PDM data Part 004: Description Methods Srie arospatiale LOTAR Archivage Long Terme et rcupration des donnes techniques produits numriques, telles que CAD 3D et PDM Partie 004 : Mthodes de d

3、escription Luft- und Raumfahrt LOTAR Langzeitarchivierung und Bereitstellung digitaler technischer Produktdokumentationen, beispielsweise 3D CAD und PDM Daten Teil 004: Beschreibungsmethoden This “Aerospace Series“ Prestandard has been drawn up under the responsibility of ASD-STAN (The European Asso

4、ciation of Aerospace Industries - Standardization). It is published for the needs of the European Aerospace Industry. It has been technically approved by the experts of the concerned Domain following member comments. Subsequent to the publication of this pre-standard, the technical content shall not

5、 be changed to an extent that interchangeability is affected, physically or functionally, without re-identification of the standard. After examination and review by users and formal agreement of ASD-STAN, it will be submitted as a draft European Standard (prEN) to CEN (European Committee for Standar

6、dization) for formal vote and transformation to full European Standard (EN). The CEN national members have then to implement the EN at national level by giving the EN the status of a national standard and by withdrawing any national standards conflicting with the EN. Edition approved for publication

7、 31 October 2005 Comments should be sent within six months after the date of publication to ASD-STAN Engineering Procedures and Processes Domain Copyright 2005 by ASD-STAN Copyright Association Europeene des Constructeurs de Materiel Aerospatial Provided by IHS under license with AECMANot for Resale

8、No reproduction or networking permitted without license from IHS-,-,-prEN 9300-004:20052 Foreword This standard was prepared jointly by ASD-STAN and the PROSTEP iViP Association. The PROSTEP iViP Association is an international non-profit association in Europe. For establishing leadership in IT-base

9、d engineering it offers a moderated platform to its nearly 200 members from leading industries, system vendors and research institutions. Its product and process data standardization activities at European and worldwide levels are well known and accepted. The PROSTEP iViP Association sees this stand

10、ard and the related parts as a milestone of product data technology. Users should note that all standards undergo revision from time to time and that any reference made herein to any other standard implies its latest edition, unless otherwise stated. All EN 9300-xxx standards quoted in this document

11、 have been either published as ASD-STAN prestandards or in preparation at the date of this standard. This document includes a Bibliography. Copyright Association Europeene des Constructeurs de Materiel Aerospatial Provided by IHS under license with AECMANot for ResaleNo reproduction or networking pe

12、rmitted without license from IHS-,-,-prEN 9300-004:20053 Contents Page 1 Scope4 2 Normative references4 3 Terms, definitions and abbreviations4 4 Applicability .4 5 Method for scope/scenario description: UML Use Case diagram5 6 Method for process description: Simplified activity diagram.6 7 Methods

13、for data description .9 7.1 General .9 7.2 Express G diagrams9 7.3 Express WHERE Rules .12 7.4 Modelling of a scenario into Express G syntax .12 7.5 Data Dictionary 13 8 Method for system architecture description: UML Package diagram .13 Bibliography14 Figures Figure 1 Used UML elements 5 Figure 2 E

14、xample UML Use case diagram. 6 Figure 3 Example of a simplified activity diagram 7 Figure 4 Hierarchy structure within simplified activity diagrams. 8 Figure 5 HTML- Representation of simplified activity diagrams. 9 Figure 6 Express G Syntax. 10 Figure 7 Example for an Express G Diagram integrate of

15、 complete diagram 11 Figure 8 Example of use of Express G Syntax . 12 Figure 9 Example for an UML package diagram. 13 Copyright Association Europeene des Constructeurs de Materiel Aerospatial Provided by IHS under license with AECMANot for ResaleNo reproduction or networking permitted without licens

16、e from IHS-,-,-prEN 9300-004:20054 1 Scope The methods are divided to four main categories: 1) Scope and scenario description 2) Process description 3) Data 4) System Architecture For scope and scenario description, the modelling methods are based on Unified Modelling Language (UML) Use Case diagram

17、s. The process descriptions are done using Simplified Activity diagrams. Data modules are described by Express G diagrams. Rules and constraints are described via Express-Where-Rules. Further descriptions, for example, for a data dictionary, are based on tabular forms. To support the development of

18、a system architecture, the modelling method of UML Package diagrams is used. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the refer

19、enced document (including any amendments) applies. ISO 10303-11, Industrial automation systems and integration Product data representation and exchange Part 11: Description methods: The EXPRESS language reference manual. EN 9300-001, Aerospace series LOTAR LOng Term Archiving and Retrieval of digita

20、l technical product documentation such as 3D, CAD and PDM data Part 001: Structure. 3 Terms, definitions and abbreviations For the purposes of this standard, the terms, definitions and abbreviations given in EN 9300-007 apply. 4 Applicability EN 9300-004 provides an overview of the used methods to s

21、upport a equal level of understanding of the standards context. EN 9300-004 recommends the usage of standardized methods. If not otherwise specified by contractual requirements, EN 9300-004 is applicable to all records which provide objective evidence covering: a) Archiving requirements b) Data qual

22、ity requirements This EN 9300-004 is applicable to existing records, on current and earlier products, produced using previous regulations. Copyright Association Europeene des Constructeurs de Materiel Aerospatial Provided by IHS under license with AECMANot for ResaleNo reproduction or networking per

23、mitted without license from IHS-,-,-prEN 9300-004:20055 5 Method for scope/scenario description: UML Use Case diagram The Unified Modelling Language (UML) is an industry-standard language for specifying, visualizing, constructing, and documenting software systems. It simplifies the complex process o

24、f software design by making a “blueprint“ for construction. The diagrams are realized with the specification of UML version 1.4. According to UML definitions Use Case diagrams identify the functionality provided by the system (use cases), the users who interact with the system (actors), and the asso

25、ciation between users and functionality. Normally Use Cases are used in the analysis phase of software development to articulate the high-level requirements of the system. The primary goals of a Use Case diagram include: Providing a high-level view of what the system does Identifying the users (acto

26、rs) of the system Within this document, a Use Case diagram is used to apply the permutation of the requirements into specific scenarios. The following UML elements are used: Process Owner /ActorReference toa Use CaseUse Caseout of currentproject scopeDomain /SystemKey domain of scenarioinclude(case

27、A includescase B mandatory)A Bextend(case B may extendcase A)A B(case A is a subtypeof case B)A BUse CaseUse Caserelevant forinterfacingFigure 1 Used UML elements The UML Use Case diagram describes the dependencies which can occur between identified use cases and involved participants (actors) withi

28、n the environment of a specific system or domain. The diagram differs between in four types of use case representations: 1) use cases 2) references to a use (further detailed descriptions) 3) use cases which are relevant within this specific domain but not relevant for the project 4) use cases which

29、 are relevant for data exchange and interfacing (Within the use case description a combination of use case representation is possible) Copyright Association Europeene des Constructeurs de Materiel Aerospatial Provided by IHS under license with AECMANot for ResaleNo reproduction or networking permitt

30、ed without license from IHS-,-,-prEN 9300-004:20056 The dependencies between the use cases are described by different line style of arrows. Dashed line arrows describe the relationships between the use cases (include or extend). Solid line arrows describe the inheritance between the use cases, solid

31、 lines describe the interaction between actors and use cases. Figure 2 gives an example. Archiving SystemProducerStart ArchivingProcessInitialization ofarchivingprocessArchive digitaldocumentsImmediatearchiving atreleaseincludeFigure 2 Example UML Use case diagram The “start archiving process” is tr

32、iggered by the actor “producer”. The use case includes the use case “initialization of archiving process”, which inherits all functionalities of the sub cases “immediate archiving at release” and “archive digital documents”. Additionally “Archive digital documents” indicates a use case which is rele

33、vant for data exchange between two systems via an interface. 6 Method for process description: Simplified activity diagram The detailed description and analysis of scenarios and resulting processes are shown by simplified activity diagrams based on the UML and IDEF0. IDEF0 is a method designed to mo

34、del the decisions, actions, and activities of an organization or system. IDEF0 was derived from a well-established graphical language, the Structured Analysis and Design Technique (SADT). IDEF0 models help to organize the analysis of a system and to promote good communication between the analyst and

35、 the customer. IDEF0 is useful in establishing the scope of an analysis, especially a functional analysis. Copyright Association Europeene des Constructeurs de Materiel Aerospatial Provided by IHS under license with AECMANot for ResaleNo reproduction or networking permitted without license from IHS-

36、,-,-prEN 9300-004:20057 The used elements for the process description are displayed in the following figure. activity (process )role decisiondatasystemmilestoneprocesssupporting processFigure 3 Example of a simplified activity diagram Every process step is started by a milestone. The use of mileston

37、es allows the integration of required references to and from other processes. In this example, the reference “validation properties”, coming from the milestone ”data preparation” displays the input information for process step “manual validation”. The simplified activity diagram identifies the parti

38、cipating roles via swim lanes. The swim lanes differentiate the various roles (persons) and systems (e.g. CAD system or the archive). The interaction between single activities within the process chain is represented by the data flow. In cases of decisions, the role has the chance to take corrective

39、action. For single process steps, a supporting process gives further information, e.g. about archiving policies for “generate package information”. To reduce the amount of information within one description level, the simplified activity diagrams are based on a hierarchical structure, following IDEF

40、0. A shadow behind a process element indicates a further detailed description for this specific process. Copyright Association Europeene des Constructeurs de Materiel Aerospatial Provided by IHS under license with AECMANot for ResaleNo reproduction or networking permitted without license from IHS-,-

41、,-prEN 9300-004:20058 The hierarchy structure is displayed within the following figure. Figure 4 Hierarchy structure within simplified activity diagrams The simplified activity diagrams will be provided via a HTML Representation. The HTML Representation simplifies the handling, the search for inform

42、ation and the navigation through the process description and is divided into two main windows: Navigation bar Process description window Within the HTML representation of the process description, the different levels are connected via hyperlinks, so that navigation between the detail levels is possi

43、ble. After a click on a process step the display will change to the next level. The HTML representation offers the possibility of getting detailed information for a single process step (blue mark in the corner of the process symbol). Further functionalities are print and zoom. Copyright Association

44、Europeene des Constructeurs de Materiel Aerospatial Provided by IHS under license with AECMANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 9300-004:20059 The following figure gives an example. navigation barprocess description windowzoom functionsprint functi

45、ondetailed definitionFigure 5 HTML Representation of simplified activity diagrams 7 Methods for data description 7.1 General The description of data uses the graphical representation of Express G Diagrams and the definition of rules and constraints via “EXPRESS WHERE Rules”. An overview of the recom

46、mended usage of entities and attributes is provided in tabular form (Data dictionary). For example, ISO 10303 (STEP) AP 214 specifies the recommended archiving data format. 7.2 Express G diagrams An Express G Diagram describes formally the used data elements and their constraints. AECMA-STAN LOTAR u

47、ses the EXPRESS-G (ISO 10303-11 version 2) as modelling method. It visualizes the logical context and the relationships between the information objects. EXPRESS-G is not a programming language, instead it is characterized by a specification language whose based on the Entity Relationship Method 2. I

48、t is possible to model objects, as well as relationships and constraints between the objects. Copyright Association Europeene des Constructeurs de Materiel Aerospatial Provided by IHS under license with AECMANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 9300-004:200510 EXPRESS-G is directly related to the EXPRESS data modelling language. Everything that is drawn in EXPRESS-G can be defined in EXPRESS. However, not everything that can be defined in EXPRESS can be drawn in EXPRESS-G. The following figure provides an overview of