governance of the s-series of ils ... - asd/aia sx000iips-c-2020-010-001-00.docx 2020-04-30 page 6...

Governance of the S-Series

IPS specifications IPS-C-2020-010

Issue No. 1.0

Copyright (C) 2020 by AeroSpace and Defence Industries Association of Europe - ASD

Publishers:

AeroSpace and Defence Industries Association of Europe

Aerospace Industries Association of America

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

Table of contents Page

1 General ...................................................................................................................... 4 1.1 Purpose...................................................................................................................... 4 1.2 Scope ......................................................................................................................... 4 2 Organizational structure .............................................................................................. 4 2.1 ASD/AIA IPS specification organization ...................................................................... 4 2.1.1 IPS Council ................................................................................................................ 4 2.1.2 Steering Committees and Working Groups ................................................................. 6 2.1.3 Steering Committee membership ................................................................................ 7 2.1.4 Working Groups ......................................................................................................... 8 2.1.5 Task Teams ............................................................................................................... 8 2.1.6 SC reporting ............................................................................................................... 8 2.1.7 Decision making in the SC .......................................................................................... 8 2.2 Transversal groups ..................................................................................................... 9 2.2.1 SX000i SC ................................................................................................................. 9 2.2.2 DMEWG ..................................................................................................................... 9 2.2.3 TWG ........................................................................................................................ 10 2.2.4 BWG ........................................................................................................................ 10 2.3 Collaboration between the SCs and WGs ................................................................. 10 2.4 Communication between the working groups and steering committees ..................... 10 2.5 Resolution of Conflicts between SC .......................................................................... 11 3 Global requirements for the S-Series IPS specifications ............................................ 11 3.1 Specification maintenance schedule ......................................................................... 11 3.1.1 Authoring rules ......................................................................................................... 11 3.2 Integration and exchange of specification data .......................................................... 11 3.2.1 Model development .................................................................................................. 11 3.2.2 Input data specifications ........................................................................................... 11 3.2.3 Data exchange ......................................................................................................... 12 3.3 Process modifications ............................................................................................... 12 3.4 Inputs to the SX001G Glossary ................................................................................. 12 3.5 Standard development and management tools ......................................................... 12 3.5.1 Tool selection principles ........................................................................................... 12 3.5.2 Approved tools ......................................................................................................... 13 3.6 Protecting the specifications ..................................................................................... 14 3.6.1 Copyright and patents .............................................................................................. 14 3.6.2 Internal documents ................................................................................................... 14 3.7 Archiving and repository requirements ...................................................................... 14 3.7.1 Archiving of SC/WG internal information ................................................................... 14 3.7.2 Published specifications and public documents ......................................................... 14 3.7.3 Archiving of IPS data ................................................................................................ 15 4 Specification publication process .............................................................................. 15 4.1 Block releases .......................................................................................................... 15 4.2 Interim releases ........................................................................................................ 16 4.3 Block release coordination ........................................................................................ 16 4.4 Initial editorial work ................................................................................................... 16 4.5 Internal ASD/AIA review process .............................................................................. 16 4.6 Public review process ............................................................................................... 17 4.7 Specification approval .............................................................................................. 17 4.8 Final publication ....................................................................................................... 17 4.9 Specification maintenance ........................................................................................ 17 5 Management of specification websites ...................................................................... 18 5.1 Domain names ......................................................................................................... 18 5.2 Domain hosting ........................................................................................................ 18 5.3 Website structure ..................................................................................................... 18 6 User community feedback ........................................................................................ 18

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

6.1 Who can provide feedback? ..................................................................................... 18 6.2 Feedback process .................................................................................................... 19 6.3 Feedback form ......................................................................................................... 19 7 Standard specification change management process ................................................ 20 7.1 Feedback evaluation ................................................................................................ 20 7.2 Change proposals .................................................................................................... 21 7.2.1 Initial evaluation........................................................................................................ 21 7.2.2 Single specification changes ..................................................................................... 22 7.2.3 Multi-specification changes ....................................................................................... 22 7.2.4 Change proposal status steps................................................................................... 23 7.3 Periodic reviews ....................................................................................................... 26 8 Translation of specifications ...................................................................................... 26 9 User forums.............................................................................................................. 27 10 Formal specification training ..................................................................................... 27

List of tables

Table 1 References .................................................................................................................. 3 Table 2 Approved tools ........................................................................................................... 15 Table 3 Feedback channels .................................................................................................... 20

List of figures

Fig 1 IPS specification committees organizational structure ..................................................... 5 Fig 2 Block releases ...............................................................................................................15 Fig 3 Block release cycle timeline example (not to scale) .........................................................16 Fig 4 Feedback form ..............................................................................................................20 Fig 5 Change proposal status steps ........................................................................................23 Fig 6 Global IPS specification change process........................................................................25 Fig 7 Translation licensing agreement process .......................................................................26

References

Table 1 References

Chap No./Document No. Title

S1000D International specification for technical publications using a common source database

S2000M International specification for material management

S3000L International procedure specification for Logistics Support Analysis (LSA)

S4000P International specification for developing and continuously improving preventive maintenance

S5000F International specification for in-service data feedback

S6000T International specification for training information

SX001G Glossary for the S-Series IPS specifications

http://www.s1000d.org/

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

Chap No./Document No. Title

SX002D Common data model for the S-Series IPS specifications

DMEWG-2018-001 UML writing rules and style guide

DMEWG-2018-002 XML Schema Authoring Rules

ISO 10303-239 PLCS Application protocol: Product life cycle support

ISO 639-1 Codes for the representation of names of languages — Part 1: Alpha-2 code

S1000D-PPWG-2013-077-003-00 Authoring rules

EN/NAS 9300 LOng-TERm Archiving (LOTAR)

1 General The development, production, publication, maintenance and management of the S-Series Suite of information are the responsibility of the IPS Council and the Steering Committees (SC) and/or Working Groups (WG) of each specification. The membership of these bodies is drawn from member companies of the Aerospace and Defence (ASD) and the Aerospace Industries Association of America (AIA).

1.1 Purpose The purpose of this document is to record the guidelines and procedures for the development, production, publication, maintenance and management of the S-Series suite of information. This includes the specifications, XML schemas, and any other auxiliary information associated to the S-Series. Such guidelines and procedures include the relationship between the IPS Council, the SCs of all specifications and the requirements for their governance.

1.2 Scope This document establishes the governance for all S-Series IPS specification groups. Change Proposals (CP) for modifications must be in accordance with the rules herein and agreed by the IPS Council. The governance described in this document does not include the maintenance of S1000D.

2 Organizational structure 2.1 ASD/AIA IPS specification organization

The Suite of information for each specification is produced by a SC that manages the development and maintenance of the specification. Each SC can be supported by WG. A special transversal working group, called the Data Model Exchange Working Group (DMEWG) works on common data issues. Terminology consistency is ensured by the Terminology Working Group (TWG) and common examples by the Bike Working Group (BWG). Refer to Para 2.2.

The coordination and global management of a SC and their WG is performed by a joint IPS Council.

2.1.1 IPS Council The IPS establishes the global policy for the specifications with the exception of S1000D. It defines the Charter for SC and WG and resolves potential disputes.

The role of the IPS Council is to maintain the vision and mission for the specifications so that the mission can be achieved, provide overall administrative management, direction to the SC for the individual specifications and provide general promotion of the use of the S-Series IPS.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

The IPS Council establishes the global policy for the specifications and defines the Charter for SC.

Specifically, the IPS Council:

resolves issues that cannot be resolved by consensus

liaises between ASD and AIA to ensure that the interests of its member’s organizations are met

liaises with the S1000D Council to ensure harmonisation

maintains the vision, mission and roadmap for the future development and maintenance of the specifications

oversees the administration of the specification’s development programs

establishes, maintains and oversees the specification’s SC

maintains the User Agreement for the "suite of information" for each of the specifications

encourages the adoption and use of the specifications by initiating educational and promotional events/materials

identifies additional areas of harmonization, within the scope of the Memorandum of Understanding (MoU)

assures the S-Series Suite of information conforms to and is compatible with other international standards and specifications such as ISO 10303-239 PLCS, where appropriate

engages with other organizations, bodies and standards to promote and support the use of the specifications

arbitrates in case of conflicts between the different SC

The organizational structure of the IPS Council is shown at Fig 1.

. ICN-B6865-IPS202001001-001-01

Fig 1 IPS specification committees organizational structure

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

The IPS Council consists of:

two members appointed by AIA

two members appointed by ASD

the Chair and/or co-Chair of each SC or WG reporting to the Council

The S1000D Council Chair or Vice Chair (depending which position is occupied by an ASD/AIA person) as an observer.

The IPS Council has a Chair and a co-Chair appointed from the AIA and ASD members whose roles rotate every two years.

The IPS Council is based primarily on consensus and detailed in the IPS Council Terms of Reference (ToR). If no consensus can be achieved, a vote is conducted under the following rules:

The AIA and ASD representatives have both veto and voting rights. Veto is only exercised in exceptional circumstances and would imply escalating the issue in question to AIA and ASD levels.

The WG and SC Chairs have voting rights but no veto rights

S1000D SC Chair or Vice Chair (also depending if an ASD or AIA person) participate in the IPS Council as an observer. The S1000D representatives in the IPS Council neither have veto nor voting rights.

The IPS Council continually monitors the structure and performance of the S-Series IPS specifications and provides direction for changes, as appropriate. The IPS Council will foster a collaborative environment throughout the entire IPS Specification community.

2.1.2 Steering Committees and Working Groups SCs and WGs are the groups dedicated to the development of the IPS specifications or to specific supporting tasks that are essential for such specifications. SCs are created by the IPS Council that work in accordance with their Charter.

There is one SC or WG for each specification. A WG is usually created to develop one single specification, and becomes an SC once the specification has been published. A WG can be also created within an SC to handle a set of permanent tasks inside an SC. In this case, the WG reports to the parent SC.

An exception is the DMEWG, which has several transversal specifications under its responsibility.

Each SC or WG has a Chair and a co-Chair, one representing AIA and another representing ASD, who alternate periodically between US and Europe. The Chairs are nominated by their respective associations (AIA and ASD).

The work performed by the SC is defined by its Charter, which is approved by the IPS Council. This includes approving any changes proposed by the SC. The SC officers seek approval from their respective associations (AIA or ASD) before submission to the IPS Council for approval.

The internal working of the SC is in accordance with the terms of reference as defined this document for all SCs. Exceptionally, a SC can have an extension of the ToRs if there are SC aspects that are not considered herein. In this case, the ToRs are submitted by the SC to the IPS Council, who ensure that the ToRs comply with the IPS Council vision, mission and policies.

A WG created by an SC can have the Charter and ToR combined into one document. Changes to that document will always be approved by the parent SC, without any need for higher-level approval.

Every SC is ruled by consensus (refer to Para 2.1.7), and in accordance with the ToRs.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

2.1.3 Steering Committee membership With the exception of the DMEWG, TWG and BWG, members of an SC are nominated by their parent organisations or MoDs/DoDs. In the case of ASD member organizations, members represent their respective nations, with a maximum of 2 votes per country and report back to their national associations. If more than two companies of a same nation participate in a SC, only the first two nominated by their national association have voting rights on the specification. AIA SC members have one vote in the SC. Refer to Para 4.7.

The members of the DMEWG are the data modellers that have been nominated by the specification’s SCs. A minimum of one data modeller is required for each specification.

The members of the TWG and BWG are the representatives to those working groups nominated by the specification’s SCs. A minimum of one representative is required for each specification.

Additional members can be approved by the DMEWG/TWG/BWG, provided that they belong to the AIA or ASD associations.

Members are expected to contribute to the development and maintenance of the specifications and attend the SC meetings. Members have unrestricted access to all the SC documentation and collaboration areas. Members, their companies and the respective national organizations who provide their national representatives accept that their participation in an SC means that any material contributed to the development of the specification can be used publicly without compensation. This means that proprietary information cannot be used or contributed by members towards the specification development without written consent by the copyright holder.

Only AIA and ASD members or MoD/DoD of the countries represented by AIA, ASD and their organisations, are allowed to participate as members or observers of an SC. The SC can also approve membership of the MoD of NATO countries that do not belong to ASD or AIA.

Observers have only limited visibility and access to the SC documentation (eg, meeting minutes and status reports) as defined in the SC ToR. Observers participating in a meeting do have a formal contribution, and their opinion is not subject to the consensus rule nor does it need to be considered by the SC. Observers do not have voting rights.

Members that do not actively participate and miss three consecutive meetings from an SC will automatically revert to observer status. If membership was due to the specific nomination of an AIA or ASD association, the specification Chair or Vice-Chair reports the lack of activity to the nominating organization and that the member has been moved to the observer status.

The SC Chairs can revert an observer back to member status if the non-participation was unavoidable, if the person in question is significantly contributing to the SC work, starts attending again regularly the meetings, or is reconfirmed by the corresponding AIA or ASD organization as a member. Re-instatement can also be proposed by any SC member but must be agreed by the SC.

Members who anticipate being absent from a number of meetings must inform their SC Chair and/or Vice Chair in order to prevent from being moved to observer status.

In exceptional cases (eg, special expertise, other standardization bodies or ASD/AIA agreements with other associations), SCs can invite individuals or members of organizations that do not belong to AIA or ASD, as invited experts. This invited expert status must be specifically reported to the IPS Council. Invited experts will have the same rights as normal observers, with limited access to the internal documentation, and can attend all meetings to which they are invited, but cannot become members of the SC.

Members having served for a significant period of time on a SC/WG may be invited to continue participation as an emeritus, even if they no longer comply with the requirements for

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

membership (eg, due to retirement). Emeritus status is granted by the SC and reported to the IPS Council. Emeritus participants will have the same rights as invited experts.

In the event that another organization signs a Memorandum of Understanding (MoU) at ASD/AIA level for the global co-development of the specifications, the companies belonging to such organization can join the affected SC as members, under the conditions agreed in the MoU.

Government and Customer organizations that have traditionally participated in the development of the S-Series specifications, such as NSPA (former NAMSA), OCCAR, EDA and LOGSA, will retain the same rights as the ASD/AIA organizations for those specifications where they have participated.

MoDs not belonging to the AIA/ASD countries or NATO can only participate in the different SCs on request by the ILS/IPS Defence Interest Group (DIG), which will forward this request to the corresponding SC Chair.

Governments, customer organisations, trade organisations, individuals or companies not affiliated with ASD/AIA cannot become SC members, unless such third party has signed a MoU with the SC for the purpose of participating in the specification development. Such membership will not be effective until this MoU has been approved by the IPS Council.

SC members of non-AIA/ASD member countries may NOT become Chairs, Vice-Chairs or Secretaries of the SCs, nor are they entitled to become members of the IPS Council. Voting rights will be as determined in the MoU.

2.1.4 Working Groups A WG is a group of individuals assigned to address specific tasks belonging to a certain subject area. WG are standing groups and are created by the SC and ratified by the IPS Council.

2.1.5 Task Teams Task Teams (TT) are groups that are created to carry out a specific task and are dissolved after the task has been carried out. A TT is approved by the individual specification SC or WG as required, and operates as directed by the SC or WG.

TT performing tasks associated with more than one specification are notified to the IPS Council and placed under the responsibility of the managing SC, who will then manage it like any other TT.

2.1.6 SC reporting The formal internal SC reporting is defined and included in specific internal SC guidelines. This formal reporting is only necessary when the SC has TTs dedicated to specific subjects, and a global vision is required by the SC members.

All SC provide a status report to the IPS Council during each of the Council meetings.

Status reports are archived in the corresponding SC/WG repository. Refer to Para 3.7.1.

2.1.7 Decision making in the SC

Decisions within an SC will be made by consensus. Refer to Para 2.1.7.1 thru Para 2.1.7.5.

2.1.7.1 Consensus Consensus requires the Chair/Vice Chair of the SC complete a check of understanding amongst the participants in the meeting of the matter to be decided upon. Consensus is a mutually acceptable agreement that takes into consideration the interests of all concerned parties.

Achieving consensus can require generating compromises. Compromise is defined as a settlement of differences or controversy through acts of concession until agreement is achieved.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

When specifically representing the interests of their nation/organization, the Chair, co-Chair and Secretary will declare this fact during consensus discussions.

2.1.7.2 Checking for understanding Before consensus, SC officers ensure that the SC has a full understanding of the issue. Opportunity for questions and clarifications must be given to ensure that reliable consensus can be reached.

2.1.7.3 Platform for disagreement Members expressing concern or disagreement over a matter brought before the group will be given opportunity to pose their argument to the group. A re-check for consensus is to be conducted following the disagreement.

2.1.7.4 Reaching consensus Reaching consensus is not a vote, and there is no weighted value given one member’s opinion over another. If a single member does not agree, there simply is no consensus. Compromises must be offered and consensus sought until it is achieved or the matter becomes irresolvable at the group level.

2.1.7.5 Irresolvable issues After repeated attempts at compromise have failed to result in consensus, a matter can still be deemed irresolvable. In this case, matters will be referred to the direct managing group (IPS Council or SC) for resolution. Sufficient information should be provided regarding arguments, counter arguments, and the need-date to allow the direct managing group to make a timely decision. The affected group will then be notified of the direct managing group’s decision.

The only irresolvable issue that could be solved by means of a vote is the publication of a specification, as it is understood that if a specification has reached the point where it can be published, most of the major issues have been already solved by consensus and a minority (perhaps even one single individual) should not have a veto right on publication. The resolution of this special case is described in Para 4.7.

2.2 Transversal groups Four groups have specific transversal responsibilities assigned by the IPS Council and provide the necessary guidelines that all SC must adhere to. These groups are the SX000i SC,DMEWG, TWG and BWG.

2.2.1 SX000i SC The SX000i SC is responsible for the definition of the top-level IPS process and coordinate the integration of the different lower-level IPS processes defined by the different specifications, as well as the interaction with other domains and the global rules to be applied for the execution of an IPS program. Each specification must nominate a representative in the SX000i SC so as to ensure that all specification processes are integrated.

2.2.2 DMEWG The Data Model ad Exchange Working Group (DMEWG) is a transversal working group that integrates and harmonizes the data models of the different specifications, as well as the exchange of information between them. The technical requirements for data modelling or data exchange are defined by the DMEWG.

The responsible data modeller for the respective S-Series IPS specifications SC/WG must also be a member of the DMEWG. This ensures interoperability between the different specifications. Each specification can also nominate additional representatives to the DMEWG.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

2.2.3 TWG The Terminology Working Group (TWG) is a transversal working group that is responsible for all terminology, so as to ensure that all the terms and definitions across the specifications are consistent.

The TWG is formed by at least one representative of each individual specification.

2.2.4 BWG The Bike Working Group (BWG) is a transversal working group that is responsible for the definition of a bike design and associated design and support data that can be shared across all the specifications, so that these data can be used as examples and for training purposes in a consistent way.

The BWG is formed by at least one representative of each individual specification.

2.3 Collaboration between the SCs and WGs The collaboration between the different groups is not only essential, but also continuous, to ensure the interoperability of specifications. The Chairs of each group will be kept informed by the Chairs of the other group on progress and issues within the individual groups, and will have a permanent position as Observers in the other group. The Chairs of all groups will communicate with each other as often as necessary for coordination and/or addressing common issues to both groups.

In particular, the different groups will work closely on topics such as:

Common tools for specification development/maintenance

Policies regarding data modelling and data exchange

Potential data gaps

Generation of the Glossary (SX001G)

Common Data Model (SX002D)

Terminology consistency

Common/shared and integrated data examples base on the ASD Bike,

Detailed guidelines for data modelling and data exchange are defined by the DMEWG. Their use is mandated for all specifications as detailed in Para 3. Providing input by each of the S-Series IPS specifications for the generation of SX001G, is described in Para 3.4.

The guidelines for the provision of new terminology and how to integrate it are defined by the TWG.

The configuration, structure, and overall guidelines for the definition and integration of examples are provided by the BWG.

2.4 Communication between the working groups and steering committees All official communications between SC will be always performed through the Chairs and co-Chairs of the respective SC of the same association. (eg, the ASD Chair of an SC would contact the ASD Chair of another SC, and the AIA Chair would contact the other AIA Chair). To expedite the communication process, an SC can nominate a representative in a different SC for all technical work, or for a specific task.

Members from different SC are encouraged to attend each other’s meetings as observers, to ensure coordination and exchange ideas across specifications. In the event that an SC identifies a potential interface and/or issue with another specification, the group will invite the Chair/co-Chair of the other SC to assist to the meeting where that issue will be discussed, or ask them to nominate a permanent representative who could inform his own group. The SCs are encouraged to nominate points of contact for each of the other IPS specifications.

In special cases where there are a significant number of common topics to be addressed, or especially important aspects to be discussed, the SC are encouraged to have a joint meeting.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

2.5 Resolution of Conflicts between SC In a similar way as the internal working of the SC, inter-group relationships are be based on consensus. If the issue is important enough, a joint session will be held between both SC.

If no global consensus be possible, the Chairs of the affected groups will appoint a specific reduced task team with members of the involved SCs, tasked with finding a compromise. If this compromise not be possible within a reasonable period of time, the issue will be escalated to the IPS Council, for final resolution.

Issues that could require agreement between specifications and are potential candidates for conflicts could be overlaps between specifications, mismatching processes and interfaces, contradicting content or change proposals impacting different specifications. Refer to Para 7.

3 Global requirements for the S-Series IPS specifications 3.1 Specification maintenance schedule

Any proposed changes to an existing specification must follow the change management process described in Para 7, so that potential impacts to other specifications are identified as soon as possible.

The change management process, used for the IPS specifications enables individual change proposals to be mapped to future specification issues, thus creating a roadmap for the evolution of the specification. Refer to Para 3.5.2.

The schedule for the publication of the different specification issues is approved by the IPS Council, so that proper alignment between the specifications is ensured and hence, their interoperability. This alignment means that the incorporation of some change proposals is brought forward or pushed back within the schedule, so that the specifications stay synchronized.

3.1.1 Authoring rules The specifications will adhere to the common Authoring Rules. Refer to S1000D-PPWG-2013-077-003-00. A chapter template is available at the IPS Council work space, and should be provided by the SC Chairs to their individual teams and stored in their individual working environments.

3.2 Integration and exchange of specification data 3.2.1 Model development

The reference standard used for the S-Series IPS specification data models is ISO 10303-239 (AP239), PLCS.

The necessary primitives from AP239 are included in the Common Data Model, so that the compliance with it by the different S-Series IPS specifications is facilitated. The DMEWG is responsible for the mapping to AP239.

Each of the S-Series IPS specification data models use, at their core, the Common Data Model as defined in SX002D by the DMEWG. The Common Data Model defines the structure of data that are shared by two or more specifications, as well as the relationships of those data.

The specification data modellers participate in the DMEWG and develop the data models of their specifications using the UML Writing Rules and Style Guide developed by the DMEWG. Refer to [DMEWG-2018-001]. The models will be developed using the approved tools as defined in Para 3.5.2 using the latest UML profile released by the DMEWG.

3.2.2 Input data specifications The specification specific data models (“process outputs”) are included with each individual specification. The inputs required by each individual specification are documented in an input data specification. These specifications have the same number as the specification for which it

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

provides input information, with the final character being replaced by an “X” (for “eXchange”). (eg, S3000X will define the data inputs required by S3000L).

The development of the input data specifications is the responsibility of the SC for which the data is provided, in coordination with the DMEWG.

If an SC finds that it needs an input that does not have a data element in the data model specification, then that SC raises a CP so that the specifications that would provide the input data can have its model changed. This CP will explicitly indicate a potential impact on SX000i and SX002D, as both the IPS process and the Common Data Model could also be impacted.

3.2.3 Data exchange Data is exchanged between the domains of the S-Series IPS specifications using XML and a set of defined XML Schemas. Each individual XML schemas is generated from the specification specific data models in accordance with the rules and guidelines defined by the DMEWG.

The specification XML schema will be mapped to AP239 as defined by the DMEWG in the XML Schema Authoring Rules. Refer to DMEWG-2018-002.

3.3 Process modifications Modifications to a specification’s production process are managed by its SC.

However, if the modification of a process affects the external specification outputs and/or modifies the global IPS process flow, then that specification’s SC raises a CP to propose changes to SX000i so that global IPS process integrity is maintained. Additional change proposals to SX002D are raised if the Common Data Model is affected by such process change.

It is the responsibility of the individual SC to track CPs raised by other specification SC that potentially impact their own input specifications. Refer to Para 3.2.2.

3.4 Inputs to the SX001G Glossary SX001G includes all terms, definitions and acronyms used across all the S-Series IPS specifications. In order to keep SX001G current, each specification SC notifies the TWG and DMEWG of any new terms, definitions and acronyms.

On each release of a new specification version, the responsible SC will provide the list of terms and definitions of the corresponding specification to the DMEWG. These are then incorporated into the next issue of SX001G.

3.5 Standard development and management tools 3.5.1 Tool selection principles

In order to ensure the compatibility and interoperability of the different specifications, a standard set of development and management tools will be defined, whose usage is mandatory for all specifications. Wherever possible, such tools will be open source, so as to ensure unrestricted access to all SC members across all specifications. In exceptional cases, when no suitable open source tool can be found, or the use of such open source implies an excessive infrastructure cost, COTS tools could be acceptable. It is not foreseen to perform ad-hoc developments for such tools, unless such tools are not publicly available.

Reasonable efforts shall be made to ensure that the selected tools are also interoperable between them as far as feasible and practical.

Should the need for a new tool be identified, the Chair(s) of the SC identifying such requirement for a new tool will report the need to the SX000i Chair(s), including rationale and potential candidates for the tool. The SX000i will consult the issue and need with the DMEWG, given its transversal cross-specification nature, as well as the suitability of such tool(s), and will raise a recommendation about the tool to be used to the IPS Council for approval. Once approved by

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

the IPS Council, such tool will become part of the standard suite of tools and will be included in Para 3.5.2.

3.5.2 Approved tools The list of currently approved tools for standards development and management is defined in Table 2. S1000D has its own toolset for development and management.

Table 2 Approved tools

Name Purpose Type Source Notes

Mantis BT Issue tracking, change proposals and community feedback for all specifications.

Open source

http://www.mantisbt.org/

Hosted on SX000i site. Contact SX000i Chair for new specification or specific needs.

Working space

Working environment for SC.

Commercial ASD Hosted by ASD. Request initial new group access through IPS Council. Refer to Para 3.7.1.

Enterprise Architect

Data Modelling Commercial DMEWG participating companies

To be used by SC Data Modellers iaw. DMEWG-2011-005, UML Writing rules and style guide

Data model quality tool

Validation of compliance of a specification data model with the UML authoring rules.

Proprietary DMEWG Tool validates compliance i.a.w. DMEWG-2011-005, UML Writing rules and style guide

Data model chapter generator

Generation of data model chapters in the different specifications

Proprietary DMEWG To be used by all data modellers for the generation of the data model chapters.

Terminology database

Single respository for all S-Series terminology and detection of different defintiions.

Proprietary TWG Updates to the database to be performed only by authorized users.

Terminology entry template

Standard format for terminology descriptions, in order to enable loading into terminology database.

Proprietary TWG To be used for all terminology definitions.

XML generator

Generation of XSD schema from data model

Proprietary DMEWG To be used by all data modellers to generate the XSD i.a.w. DMEWG-2018-002 XML Schema Authoring Rules



IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

3.6 Protecting the specifications 3.6.1 Copyright and patents

The copyright holder for all the S-Series Suite of information is ASD. Refer to the copyright pages.

The copyright pages of each specification give detailed information on:

the copyright itself

special usage rights

agreement on the use of the specification.

In special cases, the S-Series Suite of information can be trademarked and/or subject to patents in order to protect the intellectual property that they represent.

3.6.2 Internal documents The SC and WG have internal guidelines, Standard Operating Procedures (SOP) and other documents that are not intended for public use. These documents are accessible only by the SC/WG members and approved invited experts. Normal observers and the public in general will not have access to these documents.

An SC/WG approves the release of these documents to a third party if access to these documents is required for a specification-related purpose. This access will be granted by the SC/WG for a specific period of time and for a specific purpose only. The third party that has requested such access will engage in a non-disclosure agreement with SC/WG, committing to the protection of such internal documents. The approval by the SC/WG will be included in the minutes of the meeting approving this access.

All released internal documents will include a copyright statement, as indicated in Para. 3.6.1.

3.7 Archiving and repository requirements 3.7.1 Archiving of SC/WG internal information

Each individual SC/WG will have its specific working space in the common work space defined by the IPS Council. The organization of such work space will follow a common structure, but the individual SC/WG can create additional folders so as to cater for SC peculiarities.

The common workspace to be used will be the ASD Sharepoint. The individual SC/WG repositories will be hosted below Commissions/Services Commission/IPS specification Suite.

Only SC/WG members, invited experts contributing to the development work and IPS Council members will have access to this SC repository. The requests for access for new members/revoking rights for people having abandoned the SC/WG, will be managed by the SC Chair(s).

All the SC/WG information, including historical documents, will be preserved in this work space, for future reference. This information includes, but is not limited to, meeting agendas and minutes, status reports, position papers, working documents, old specification versions, change proposals, etc. Documents that must not be modified such as approved meeting minutes, status reports, change proposals, published specifications, etc, will be stored in PDF format, all other documents will be stored in the original format.

During the production and publishing of every specification, its master chapter documents, graphics files, output files and the published specification are archived both in the repository and on a hardware copy.

3.7.2 Published specifications and public documents Every time that a new specification issue is generated, a CD-ROM will be generated with both the source files (original master text files, data model, graphics, etc) and the final publication document. All CD-ROMs are to be permanently marked with: “SNNNNY, version x.y, issue date YYYY-MM-DD” and include the signature of the Chairmen concerned.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

The CD-ROMs are to be sent to:

ASD AIA Rue Montoyer 10 1000 Wilson Boulevard, Suite 1700 B-1000 Brussels, Belgium Arlington, VA, 22209, USA

After the submission of the CD-ROM, the SC Chair will report this fact to the IPS Council and the ASD PSSG Chair.

Each specification has its own website where issues of them are made available to the public. These websites are:

ASD-STE 100 www.asd-ste100.org

S1000D www.s1000d.org

S2000M www.s2000m.org

S3000L www.s3000l.org

S4000P www.s4000p.org

S5000F www.s5000f.org

S6000T www.s6000t.org

SX000i www.sx000i.org

All transversal specifications (SX001G, SX0002D, etc): www.sx000i.org

3.7.3 Archiving of IPS data To ensure an effective archiving mechanism for all IPS data, and to ensure the interoperability with other archiving mechanisms (eg, for Engineering information), IPS data will be archived using the specification developed by the LOng Term Archiving and Retrieval (LOTAR) project, EN/NAS 9300 and all IPS Specifications will use this common mechanism.

4 Specification publication process

4.1 Block releases The IPS Council has agreed to perform a block release for all S-Series specifications, with the exception of S1000D. This means that all specifications will be published at the same time, so as to ensure the interoperability of the whole S-Series Suite of information.

The cycles of the different block releases will overlap, so as to ensure that each SC/WG can continue working without having to wait for all the editorial work to finish. This situation is shown in the following Fig 2.

ICN-B6865-IPS202001002-001-01

Fig 2 Block releases

This block release will take place every two years, at a date set by the IPS Council. The IPS Council may shift this date or delay the block release by an additional year if it considers that

http://www.asd-ste100.org/

http://www.s1000d.org/

http://www.s2000m.org/

http://www.s3000l.org/

http://www.s4000p.org/

http://www.s5000f.org/

http://www.s6000t.org/

http://www.sx000i.org/

http://www.sx000i.org/

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

there is a justification for this delay. An example could be that an extremely complex change needs to be performed that cannot be included in a two-year cycle.

Note that it is not mandatory that a specification is updated for a specific block release. A specification may remain unchanged in two consecutive block releases if there are no multi-specification changes that affect it.

4.2 Interim releases In order to speed up the editorial process and the actual publication, the individual SC/WG may perform internal interim releases so as to consolidate a set of change requests. These interim releases will maintain the compatibility with the latest version of the Common Data Model and the overall IPS process defined by SX000i, even if they are not to be published separately.

Interim releases will be only available within the corresponding SC/WG and must not be published. In exceptional cases, however, the IPS Council may authorize to publish an interim release, separately from the common block release cycle.

4.3 Block release coordination In order to ensure the proper coordination between specifications, the IPS Council will issue a timeline before each new update period. This timeline will include the different mandatory milestones to be complied by each specification.

ICN-B6865-IPS202001003-001-01

Fig 3 Block release cycle timeline example (not to scale)

4.4 Initial editorial work The specification is reviewed by an editorial team that is made up of members of the specification’s SC. This team’s responsibility is to ensure that all changes satisfy the details of any CPs, comply with the requirements detailed in this chapter, and follow the Authoring rules. Ref. [S1000D-PPWG-2013-077-003-00].

Once the initial editorial work is complete, the editorial team publishes a PDF that is delivered to ASD/AIA for internal review and commenting.

4.5 Internal ASD/AIA review process The specification is made available to ASD/AIA members for review by uploading to a protected area of a website. This fact is reported to the ASD/AIA national bodies, who in turn inform their member companies and national MoD/DOD.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

Member companies then provide comments within the review period, in accordance with the Feedback Process. Refer to Para 7.

After the review period the SC reviews the comments and provides appropriate responses.

When all agreed comments have been incorporated, the specification is published a second time for public review.

4.6 Public review process At this time, the S-Series Suite of information is made available to the public, for further review, to take advantage of any potential contribution from subject matter experts who belong to non-member companies.

The draft is published on the corresponding specification’s website, clearly marked as a proposed draft, inviting the general public to submit comments using the feedback process. Refer to Para 6.

Comments received are handled in the same way as that for the internal ASD/AIA review process. Refer to Para 4.5.

In some cases, the public review process can be shortened or cancelled with the approval of the IPS Council.

4.7 Specification approval ASD/AIA approval is required for all issues of the S-Series IPS specifications prior to publishing. To this effect, the final corrected specification is approved by the specification SC by consensus and in accordance with its ToR.

If consensus cannot be not be reached, there is a formal vote by the SC full members, with one vote per country and one per MoD/DoD. Should there be several national representatives for a same country, then they must agree previously the sense of their vote or, if they cannot agree, abstain from voting. Observers do not have a vote.

If the vote results in approval, the publication takes place. The concerns of those opposing publication are minuted so that they can be addressed in the future.

If the vote does not result in approval, the problem is escalated to the IPS Council for resolution.

Once the SC has approved publication of the specification, the IPS Council is informed, and it authorizes the publication as part of the next block release or, on an exceptional basis, as a stand-alone release.

4.8 Final publication Final publication of all the S-Series specifications will be approved by the IPS Council.

Once the IPS Council has approved the publication of the specification, these will be published on the individual specification websites.

As agreed as part of the joint AIA /ASD MoU, all IPS specifications will be made available to the public free of charge.

4.9 Specification maintenance Maintenance of a specification consists of updating in response to CPs, or updating to keep pace with new business needs detected by the specification’s SC or IPS Council. All proposed changes, whether from within the SC or from the public, are documented as technical issues and tracked. Refer to Para 6. The proposed changes are then processed, following the Change Process. Refer to Para 7.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

5 Management of specification websites Each of the specifications has its own website, providing background information the facility for direct interaction with its users.

5.1 Domain names Each specification has a domain name that corresponds to the specification number, followed by the top-level domain “.org”. (eg, S2000M.org, S3000L.org).

The IPS Council appoints an overall domain manager, who reserves and renews the domain names on behalf of ASD/AIA. The domain manager has a deputy who provides backup, as required.

When a new specification is launched, the domain manager reserves the appropriate domain name to preserve the specification’s website.

5.2 Domain hosting The IPS Council approves a single hosting company who will host all the S-Series IPS specifications in accordance with criteria set by the domain manager.

Each specification’s SC appoints a webmaster who manages the website in coordination with the IPS domain manager.

5.3 Website structure A common website structure template is defined by the domain manager and approved by the IPS Council. All specification websites retain the same structure, and look and feel, applying to the domain manager, with any structural change proposals. Approval follows the same process as specification approval. Refer to Para 3.7.2.

Each website will provide information about its own specification only, referencing the other IPS specification websites as necessary. A “Links” page will provide links to all other specifications.

All cross-specification aspects will be hosted on the SX000i.org website, and the other websites will have to reference this site for common elements.

6 User community feedback Feedback from the IPS user community is welcome and encouraged and will receive the appropriate attention.

6.1 Who can provide feedback? The IPS user community that can provide feedback is considered to include AIA and ASD and their member organizations, their national MoD and the user community at large. Table 3 indicates the means through which such feedback must be provided. In all cases, the feedback must be sent to the SC of the affected specification.

Table 3 Feedback channels

Who Through Notes

SC members SC Companies should channel feedback through their SC representatives

AIA members National SC representative(s)

If no national representative exists, through the AIA SC Chair

ASD members National SC representative(s)

If no national representative exists, through the ASD SC Chair

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

Defence Interest Group (DIG)

SC Chair(s) One of the DIG nations can present it through the corresponding SC in which it participates, indicating that it is acting on behalf of the DIG.

MoDs/DoD National MoD/DoD representative in the SC or the DIG.

If the MoD/DoD does not participate in the SC, through the DIG or their national industry representative (for US DoD: AIA Chair) or ASD SC Chair if there is no national representative.

NSPA, OCCAR, EDA

Representative in the SC or the DIG.

If the organisation does not participate in the SC nor the DIG, through one of their national representatives or through the SC Chair.

General Public AIA or ASD SC Chairs Only to published specifications

6.2 Feedback process The feedback related to an individual guide/specification must always be performed in accordance with Table 3.

Feedback across specifications, cross-specification issues or feedback about missing content is reported to the SX000i SC. The SX000i SC will evaluate the cross-specification, who will assess the impacts. If a single specification is impacted, the SX000i SC directs the feedback to that specification’s SC.

If the assessment identifies that the issue is related to the overall IPS process, global interfaces, or any other common issue, the SX000i SC takes responsibility for the issue, creating a sub-issue for each individual specification. Refer to Para 7.1.

If the multi-specification issue is only related to the common data model (SX002D), detailed interfaces or data exchange, the SX000i SC will hand over the responsibility for the issue to the DMEWG. Refer to Para 7.1.

Reporting feedback uses a change proposal (CP) management website. Refer to http://www.sx000i.org/CPF/. Visitors to the website are required to register to gain access; however, registration is free of charge. Refer to Para 6.1.

Note that feedback that does not comply with the rules given in Para 6.1 can be discarded or deleted without explanation. The feedback form within the tool is shown in Para 6.3.

A response will be provided to the user by the designated national or organizational representative. Based on the feedback, a CP is raised for the affected specification. Refer to Para 7.2.

6.3 Feedback form The form through which feedback is provided is shown at Fig 4.

.

http://www.sx000i.org/CPF/

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

ICN-B6865-IPS202001004-001-01

Fig 4 Feedback form

Providing information in those fields marked with a * is mandatory in order for the form to be accepted and the feedback process started.

Feedback can provide an answer to the originator of the technical issue, or it can trigger a CP. Refer to Para 7.

7 Standard specification change management process The change management process is applied to the S-Series Suite of information, so that interoperability is ensured.

The standard change management process manages changes affecting a single specification or multiple specifications. The process coordinates changes across multiple specifications and manages delta changes and the timeline associated with CPs. This allows monitoring CPs, proposed by any SC, independently of the specification(s) affected. It is also possible to monitor CPs made by the S-Series IPS specification’s SC to other standardization bodies to ensure interoperability of the S-Series Suite of information with those of other domains.

Changes to specifications are always generated based on CPs and only SC members from any of the specifications and the IPS Council can generate them. The user community can only raise issues through the feedback process described in Para 6. Evaluation determines whether the raised issue becomes a formal CP or not.

7.1 Feedback evaluation All feedback received is evaluated through the appropriate feedback channel. Refer to Para 6.1. If this is the respective SC Chair, then the evaluation of the feedback is assigned to one of the appropriate SC members to ensure that all SC members contribute. The SC Chairs can also

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

reassign a specific issue to a specialist, in case the issue presents special challenges. The lead for a specific feedback issue is called the Technical Issue Contact Point (TICP).

All issues are given a unique tracking number, and a unique TICP. The TICP will evaluate the impact and fidelity of the issue, and request further information from the originator, so that all the information is reliable and complete. If necessary, specialists within the SC can be involved to confirm that there really is an issue.

If the initial assessment indicates that several specifications are affected, then the technical issue is transferred, by the specification’s SC that received it, to the SX000i Chair, who will appoint a lead, who acts as a TICP and creates a team from the individual affected specifications. If the initial assessment shows that only the common data model or the technical interfaces between the specifications (data exchange) are affected by the issue, then it is assigned to the DMEWG.

If the issue is already covered by an existing issue or CP, the TICP associates the issue to the SC that is managing that issue or CP, in order to prevent duplication of effort.

After assessment of the issue, the TICP will provide a response to the user/originator and close the technical issue, or process the issue into a CP.

7.2 Change proposals The user community at large is not allowed to raise a CP, only raise technical issues through the feedback process described in Para 6, which, after evaluation and acceptance, can be converted into a CP.

However, CP to a specification can be raised directly by:

TICPs to confirm that a technical issue is a real problem

SC members (only to their own specification)

Other SC, requiring a change from a different specification

IPS Council members

7.2.1 Initial evaluation An initial evaluation confirms whether the CP is a legitimate problem or not. Information on five points are provided for the initial evaluation before the any further progress in the process can be made. These five points are:

impact

purpose

coverage

requirement

justification

7.2.1.1 Impact

The impact indicates which of the S-Series IPS specifications are potentially affected by the CP.

7.2.1.2 Purpose The purpose of the proposed change must be clarified in terms of:

Enhancing capability or adding new functionality

Clarifying or refining existing capability or functionality

Editorial changes

Bug fixes or corrections

7.2.1.3 Scope The scope is an indication of the location in the specification that is impacted by the CP. This includes, but is not limited to:

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

Chapter text

XML Schemas

Data Model

Data Exchange

Exchange business rules

Sample files

7.2.1.4 Requirement justification CPs not only describe the requirement for the change but also the justification for the proposal. Justification can include, but is not limited to, explanations of:

How the current specification does not meet the requirement

The benefit(s) that the requirement adds

The use cases that support the requirement

How the requirement supports the global IPS process, or the Council’s vision, mission and goals statement

All CPs provide this information before they can be evaluated by the appropriate SC. If the information is not provided, the CP will progress no further.

Once this initial evaluation has been performed, the TICP will present the CP to the SC where the issue was raised, for further evaluation. If the SC agrees that it is a potential CP, then the process continues. Otherwise the CP status is reverted back to an issue. A response is prepared to the originator of the issue, and it is then closed.

If a CP affects only one specification, then the corresponding SC processes the CP. Refer to Para 7.2.2.

If a CP potentially affects more than one specification, the responsibility for the CP is transferred to the DMEWG in case that the CP affects the data model, and to the SX000i SC if it affects the overall process. The DMEWG or the SX000i, after assessment, might transfer it back to the original specification if they consider that the change has no impact on other specifications, in which case it will be processed as a single specification change as per Para 7.2.2.

If the DMEWG or SX000i SC confirms that the CP affects more than one specification, then the CP will be managed as indicated in Para 7.2.3.

7.2.2 Single specification changes Once a CP has passed initial evaluation and is accepted by the affected SC as a proposed CP, the SC processes the change proposal internally, so that it is incorporated in the specification. Implementation of this specification-specific CP is the responsibility of the respective SC in accordance with its own internal processes.

If the CP in question is a child of a multi-specification CP, the SC is responsible for coordinating its incorporation with the SC that is responsible for the parent CP. Refer to Para 7.2.3. If the CP is not related to any other specification, then responsibility lies exclusively with the affected SC.

7.2.3 Multi-specification changes Upon assignment of a CP, the SX000i SC or DMEWG analyses it and generates associated child issues and/or CRs, as required, to each of the affected specifications, which processes the change. Refer to Para 7.2.4.

The CP remains open until all child issues and/or CPs have been closed by the impacted specifications. The SX000i SC or DMEWG ensures that the responses from the different SC are aligned. If they are not aligned, the SX000i SC or DMEWG assists the SC to reach consensus. If consensus still cannot be achieved, then the CP is escalated to the IPS Council for guidance and direction.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

Once a common approach has been agreed, the CP is coordinated so that the corresponding changes are made in a timely manner. Incorporating the changes to each specification is performed as described in Para 7.2.4. In particular, it must be ensured that all specifications embody at the same time the corresponding change for a specific specification block release.

The block release into which a multi-specification change will be embodied will be agreed by consensus by the affected specification chairs. If no consensus can be reached, the issue will be escalated to the IPS Council.

Notwithstanding the above, all specifications must update in each release to the latest version of the Common Data Model (SX002D), as defined during the release block period. Should it not be possible to update a specification data model to the latest version of SX002D in the block release timeframe, then the specification data modeller must report this to the DMEWG before the actual publication of the new SX002D version.

Multi-specification changes may not be embodied in a block release unless all the affected specifications have incorporated that change, ie, the parent CR has been closed.

7.2.4 Change proposal status steps As an issue or CP moves forward in the process, the status of the issue or CP changes. Refer to Fig 5

ICN-B6865-IPS202001005-001-01

Fig 5 Change proposal status steps

New: The issue or CP has been received, registered and published on the website, and is ready for assessment.

Acknowledged: The issue or CP has passed initial validation; a TCIP has been assigned and is under review by the corresponding TCIP.

Feedback: The issue or CP lacks information, either for the initial evaluation and/or for the technical solution. The returned issue or CP will include comments to enable the originator to provide the missing information.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

Confirmed: The issue has passed the initial evaluation and the TCIP has confirmed that the issue or CP has all the necessary information and provides the necessary justification; the issue is now a formal CP to the specification. Refer to Para 7.2.1.

Assigned: The CP has been assigned to an SC member or to a different SC for resolution and additional issues have been raised to other affected specifications as necessary. Refer to Para 7.2.3.

Closed: The issue does not require a CP, and an explanation/clarification is provided to the originator. Note that a closed issue may be reopened by the originator in case that the response is not satisfactory.

Resolved: The solution to the CP has been approved by the SC and has been incorporated into a new specification release.

Fig 6 shows the global progression of an issue/CP through the change process in more detail and shows the various responsible parties.

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

ICN-B6865-IPS202001006-001-01

Fig 6 Global IPS specification change process

S - Series Change Process

User / Initiator TICP SX 000 i / DMEWG Steering Committee ( s ) Council Publication

Identif y all a ffected Specs and data

elements

Define solution i . a . w . internal SC process

Assess Isue

Assign Issue Contact point

Respond Issue & close it

Assess impact

Non Consensus Resolution

Established Task T eam for conflict

resolution

Production Coordination

Agreement ?

No Yes

Conflict resolved ?

Yes

Initial assessment

More info required ?

No

Multi - spec ?

Provide information Yes

Change request necessary ?

No

User informed

Perform initial evaluation

Yes

No

Yes

Assign to SX 000 i / DMEWG

User raises Issue

IPS - C / SC raises Change Request

Multi - spec confirmed ? No

Yes

Raise child change request to affected

Specs .

Notify SX 000 i / DMEWG of

proposed solution

Disposition changes for their relevant SC

changes u sing their own

process to appr o ve at SC level

Part of multi - spec . change

request ?

Yes

No

No

By ASD / AIA

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

Once the changes have been made, the corresponding CP is complete and archived with an annotation that indicates which issue of the specification it was incorporated. Refer to Para 4.

7.3 Periodic reviews

It is expected that changes to a specification will be requested periodically, so that it naturally evolves with time. Notwithstanding that, the IPS Council assesses the status of each specification every five years, to ensure that it is still valid and meeting the IPS business requirements.

If it is found that the specification requires changes, then the IPS Council tasks the corresponding SC to implement those changes. If the IPS Council considers that the specification no longer meets a specific IPS business need, then the IPS Council decides whether to cancel the specification and stand down the corresponding SC.

8 Translation of specifications

The S-series IPS specifications and other associated documents are officially published in English only. However, national industry associations (whether members of the ASD/AIA or not) can request permission to translate the specification into their own language(s) using the license agreement template, which is available from the IPS Council.

Though the request for a translation can, in principle, be received by any member of the ASD/ AIA community, the formal process for the authorization of the translation is shown in Fig 7.

ICN-B6865-IPS202001007-001-01

Fig 7 Translation licensing agreement process

The translated specification is allocated its own number in the form of “Sn00nxLL”, where “Sn00nx” is the number of the original specification and "LL" is the two-character language code (eg, "ZH" for Chinese or “ES” for Spanish). Refer to [ISO 639-1].

IPS-C-2020-010

Applicable to: All

IPS-C-2020-010-001-00.docx 2020-04-30

9 User forums User forums are formal events at which the user community promote the S-Series IPS specifications, provide training, receive feedback and exchange experiences with their use.

For example, the IPS Council is responsible for the framework of the user forums and approves:

host nations/organizations/locations

forum themes

proposed conference fees

Proposals for new User Forums will be raised by the Chair of the proposing Steering Committee to the IPS Council for approval. The organization of such User Forum, once approved, will be delegated by the IPS Council to the corresponding SC. Multi-specification User Forums will be organized by the IPS Council or delegated to a specific SC on a case-by-case basis.

The IPS Council will also ensure the alignment of User Forums to its vision/mission.

10 Formal specification training ASD/AIA plan to set up formal training courses for all S-Series IPS specifications. These training courses will only be provided by certified trainers. The trainer certification is provided on a specification-by-specification basis.

Once training courses have been defined, the IPS Council will sign a MoU with one or several companies or organizations to provide such formal training.

Organizations that have signed such MoU with the IPS Council will be considered certified trainers for the duration of the MoU. Certification can be revoked if the organization in question does not adhere to the terms of the MoU or the quality of their training proves to be inadequate.

Individual SC members and invited experts, who have actively participated in the SC and contributed to the specification for at least two years, will on request be granted the certified trainer status by the corresponding SC for the specification issue to which they have contributed. Such request shall not be unreasonably denied.

SC members and invited experts may retain their certified trainer status for the duration of their participation in the SC and up to five years after the member or invited expert has abandoned the SC. The certified trainer status may be revoked by the SC in the event of exceptional circumstances that recommend revoking such status.

Normal SC observers may not become certified trainers unless they have followed the formal training course for trainers.

Certified training credentials will be allocated for a single specification version. The SC may internally agree to provide several certification levels or for specific specification chapters.

The SC Chairs will hold a list of all certified trainers for their associated specification and report this list to the IPS Council. Individuals or organizations seeking formal training on a specification may contact the corresponding SC Chair for contact data of certified trainers offering external training services.

End of data module End of data module