Transport NSW | for NSW TS 10507: 2013 Management standard AEO Guide to Systems Integration Version 1.0 Issued Date: 30 August 2013 Effective Date: 30 August 2013 Important Warning 1k owned or managed by he NSW on tin any way unless (© State of NSW through Transpot for NSW Page 1 of 24Standard Approval Owner: Authorised by: Approved by: Document Control Version 1.0 Manager, Systems Engineering Process Principal Manager, Authorisation and Audit Director, Asset Standards Authority ‘Summary of Change First issue For queries regarding this standard We NSW Transport Asset Standards Authority standards(@esa anspor. [Link].2u [Link].0u (2 State of NSW through Transpod for NSW TS 10507: 2013 ‘AEO Guide to Systems Integration ‘version 1.0 Effective Date: 20 August 2013 Page 201 24TS 10507: 2013 ‘AEO Guide to Systems Integration ‘version 1.0 Effective Date: 20 August 2013 Preface The Asset Standards Authority (ASA) is an independent body within Transport for NSW whose Purpose is to drive excellence in asset standards management by creating opportunities for increased innovation, while ensuring safety and efficiency in design, construction and delivery. The ASA is responsible for engineering governance, assurance of design safety, and ensuring the integrity of transport and infrastructure assets. The ASA promotes and contributes to the development of industry capability by developing and publishing guidance material on orgenisation-level competency frameworks, thereby promoting development of technical and engineering capability. This AEO Guide to Systems integration has been developed on the technical processes of ISO/IEC 15288-2008 by the Asset Standards Authority establishment team, reviewed by a consultative group containing members from Transport for NSW stakeholder groups, and ‘approved by the Asset Standards Authority This AEO Guide to Systems Integration forms one of a suite of systems engineering documents and guidance notes written to help engineering organisations understand the Asset Standards Authority's interpretation of systems engineering processes. (2 State of NSW through Transpod for NSW Page 30f 24TS 10507: 2013 ‘AEO Guide to Systems Integration ‘version 1.0 Effective Date: 20 August 2013 Table of contents 1. 2 24 22 a a4 32 10. 10.4 10.2 10.3 10.4 1. 12. Appendix A - Example interface register Appendix B - Example interface control document. PUIPOSE eran ‘Scope.. Application Reference documents... International standards Australian standards, acts and regulations... TINSW and ASA standards Other references. Terms and definitions ...ninenmsnnes ‘Systems integration requirements... ASA interpretation of systems integration. Interface management. Interface management activities. Planning interface management. Identifying and analysing interface Controlling interfaces Reviewing interfaces. Interdisciplinary design review process. ‘Systems integration. Purpose of systems integration .. ‘Systems integration activities jn ‘Systems integration outputs. Roles and responsibilities .nnssnsemmnnnnnnnnnnnnes Element design lead... RECOPS sn Railway station example... Appendix C - Example interface management pla ..[Link] ds Appendix D — Interdisciplinary design review process ......uunnmnnnnennainnnnne (© State of NSW through Transpot for NSW Page 4 0f 2624 22 3.1 3.2 1310507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 Introduction The Asset Standards Authority (ASA) has established an engineering framework based on systems engineering principles and methods that include systems integration and interface menagement. Authorised Engineering Organisations (AEOs) should implement this framework to manage Transport for New South Wales (TfNSW) engineering activities over the total asset life cycle. Purpose ‘The AEO Guide to Systems integration establishes recommended interface management and systems integration management principles and methodologies for AEOs engaged in providing engineering services to TINSW, particularly systems integration services, ‘The AEO Guide to Systems Integration further develops the guidance described in the AEO Guide fo Engineering Management. Scope This systems integration guidance has been based on an expansion of the technical processes of ISO/IEC 15288:2008, It focuses on the ASA's interpretation of systems integration in the context of work performed by AEOs on behalf of TINSW. Application This guidance document is primarily intended for application by AEOs conducting systems engineering activities related to the engineering services provided on behalf of TINSW. ‘The guidance provided in this document applies to organisations applying to be authorised to carry out engineering activities on behalf of TINSW. This includes organisations responding to tenders, and those applying to be pre-registered as an Authorised Engineering Organisation in order to be considered for tendering for TINSW work, This guide is not mandatory, but it does provide general recommendations for prospective ‘AEOs, and is tailored to address high-level systems integration requirements. Reference documents References in the text relate to latest editions unless specific edtions are cited International standards ISO/IEC 15288:2008 Systems and software engineering ~ System life cycle processes Australian standards, acts and regulations ‘AS 42922006 Railway Safety Management (parts 1, 2, 3, 4 and 5) (2 State of NSW through Transpod for NSW Page 5 of 243.3 3.4 Ts 10507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 TiNSW and ASA standards TS 10500 AEO Authorisation Governance Framework TS 10501 AEO Guide to Authorisation ‘TS 10802 AEO Authorisation Requirements TS 10504 AEO Guide to Engineering Management, TS 20001 System Safety Standard for New of Altered Assets Other references INCOSE TP-2003-002.03,2.2 Systems Engineering Handbook. A guide for system life cycle processes and activities SEBoK v1.0 Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0 Terms and definitions “The following terms and definitions are used inthis document: (AEO Authorised Engineering Organisation ASA Asset Standards Authority assurance isthe evidence of effective management authorisation the conferring of authorty, by means of an official instruction and supported by assessment and audit authorised engineering organisation a supplier of a defined engineenng service or product that has been assessed and granted AEO status by TINSW compliance the state or fact of according with, or meeting, rules or standards ICD interface control document, Alternatively referred to as ICS Interface Control Specifications, IDR Interdisciplinary Design Review. Alternatively referred to es IDC Intercisciplinary Design Check. NN’ diagrams 2 graphical representation to define the internal operational relationships or external interfaces of the system of interest responsible a duty or obligation to satisfactorily perform or complete a task (assigned by someone, of created by one's own promise or circumstances) that one must fulfil, and which has @ consequent penalty for failure. Responsibility can be delegated. review a method to provide assurance by a competent person that an engineering output complies with relevant standards and specific requirements, is safe, and fit for purpose ‘SME subject matter expert {© State of NSW through Transpod for NSW Page 6 of 241310507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 SQE safety, quality and environment subject matter expert a person assessed or recognised as having the highest level of competence (including knowledge, skills and practical experience) in a particular field or discipline. This is typically a professional head of discipline or technical director. supplier a supplier of services of products. Defined as an ‘applicant’ until such time as it has been granted AEO status, after which itis referred to as an AEO. TINSW Transport for New South Wales 5. Systems integration requirements The ASA AEO Authorisation Requirements states the following mandatory requirements for Systems Integration “An Authorised Engineering Organisation shall have interface management arrangements that set out the process, responsibilities, structure, tools and deliverables” “An Authorised Engineering Organisation shall ensure that all interface requirements under the control of its engineering services are identified, captured and managed” “An Authorised Engineering Organisation shall ensure that interface design reviews and checks are conducted at appropriate stages of the design process by competent subject matter experts” “Authorised Engineering Organisations shall identity and manage interface risks and outcomes that may have a safety impact" “An Authorised Engineering Organisation that intends to offer rail systems integration services shall demonstrate that it has suitable management arrangements to plan and carry out the integration of all the declared systems" 6. ASA interpretation of systems integration ‘System integration is bringing together component elements into one system, ensuring that the elements function together as 2 complete system, and ensuring the new system integrates within the existing system of systems. ‘Systems integration as defined within ISO/IEC 15288:2008, deals specifically with the assembly of implemented elements, and verification of the system against its design properties, The ASA has broadened the application of the term ‘systems integration’ to include the technical effort required to simultaneously design and develop the system, and the associated engineering processes through consideration of all life oyole stages and needs. (2 State of NSW through Transpod for NSW Page 7 of 247A 7.2 1310507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 The ASA has included the activities of interface management across all life cycle stages in its definition of systems integration. This includes the need for interdisciplinary coordination; and design reviews at key project stages, As a result, this guidance decument includes the key systems integration activities defined in ISO/IEC 15288-2008, as well as details of interface management and interdisciplinary design review activities Interface management Interface management is performed to ensure that discrete elements and systems can function together to achieve the planned emergent properties of an integrated system. Interface management includes definition, analysis, contral, and communication of information, Interface management activities Interface management activities should include the following: + plan interface management * identify, define and analyse interfaces + control interfaces + review interfaces The output of the interface management activities should be formally documented, as they form ppart of the evidence that supports systems and safety assurance, Planning terface management ‘An interface management plan should be prepared to specify the processes for the identification, analysis and control of interfacing systems and elements, both internally and with external parties, ‘An interface management plan typically provides processes for the following interface management actions = Identity the subject system and its component elements that require intra-system interfacing + Identity the systems external to the subject system that require inter-system interfacing + assign responsibility and authority for interface management in all interfacing organisations or teams * specify the information to be exchanged over inter-system and intra-system interfaces = identify the interface requirements included within the scope of works (2 State of NSW through Transpod for NSW Page 8 of 2473 1310507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 * identity the interface requirements derived in design, development, installation, integration, testing and commissioning of the interfacing systems and elements + identity the technical strategy for developing, testing and deploying each interface, including specification of the requirements, design and testing documentation = establish the development schedules, including identification of resources required to manage interfaces through the system life cycle stages * specify the management and technical skills required at each stage of the system life oyole + verify and validate the interface process specify the configuration management and quality management procedures relevant to interface development, including identification of major gate reviews = identity a strategy for the management of safety, or a cross-reference to the appropriate safety management procedures, including references to an interface hazard analysis register ‘An example interface management plan is shown in Appendix C. Identifying and analysing interfaces The following steps should be followed to identify and analyse interfaces * define the interfaces + Identity the interface sources = capture the interfaces in a matrix Definitions of interfaces Interfaces are the functional, physical or informational characteristics which exist at common boundaries between items. Interfaces allow systems, equipment, software, personnel and data to be compatible and operate successfully with each other. Three types of interface are functional, physical, and information ‘A ‘Tunctional system interface’ exists between two different systems, inclucing two different elements. Such an interface arises when one or more functions within one syste interact with ‘one or more functions in another system. For example, when fire detection system identifies a potential system event and an alarm is activated at the relevant control desk A logical interface is @ subset of a functional system interface, ‘A ‘physical system interface’ is @ physical or passive item of equipment, or link between the two sides of the interface. For example, cable trays supporting communication cables. (2 State of NSW through Transpod for NSW Page 901247.3.2 7.3.3 Ts 10607: 2013, ‘AEO Guide to Systems Integration Version 1.0 Effective Date: 30 August 2013 ‘An ‘information system interface’ is the exchange of information between people or parties that enables the project, product or service to proceed. For example, issuing design drawings to another design discipline. Another example is the exchange of manual records between people in operations, based on paperwork logs or record sheets. Interface sources Every interface represents @ potential risk All interfaces should be identified, defined and analysed during architectural and functional system design, prior to commencing any physical design activities. The key sources of information for identifying interfaces include the following + existing standards end interface agreements + stakeholders, including enterprise, users, operators and maintainers * stakeholder specifications and scopes of work * architecture use cases + concept and reference designs + the environment within which the product or service will funetion + affected third parities Interfaces can also be identified or derived through functional analysis of stakeholder requirements, and can exist within the required product or service. These are referred to as internal interfaces. Interfaces between the desired product or service and the surrounding environment are referred to as external interfaces. Interface matrix ‘An interface matnx provides an overview of all known high-level interfaces for the system of interest, as defined by the project scope, This matrix assists in the intial definition and planning of interfaces, and associated analysis. A common type of interface matrix is an N* (N-squared) diagram. An NF diagram is @ visual matrix, which requires the user to generate complete definitions of all the system interfaces in a bi-directional, fixed framework. Producing an N? diagrams requites a systematic approach to identity, define, design, analyse, and document functional interfaces. N? diagrams can be applied to both intra-system and inter-system systems interfaces, which include hardware interfaces, software interfaces, human-machine interfaces, and external environment interfaces. A key advantage of using N* diagrams for the management of both inter-system and intra-system, interfaces is the identification of areas where conflicts may arise between functions. {© State of NSW through Transpod for NSW Page 10 of 241310507: 2013 ‘AGO Guide to Systems integration ‘Version 1.0 Effective Date: 30 August 2013 The 'N' in an NF diagram is the number of entities for which relationships are shown. The key system functions are placed on the chart diagonal. The rest of the squares in the N# matrix represent interface inputs and outputs. Interfaces between functions flow in a clockwise direction, When a blank appears, there is no interface between the respective functions, When alll functions have been compared to all other functions, then the chart is complete. An example of an N? matrix is illustrated in Error! Reference source not found.. Figure 1 -N? interface matrix for railway systems. 74 Controlling interfaces ‘The following documents are used as tools for controlling interfaces: + interface register interface contro! document 7.4.4 Interface ret Having identified all known high-level interfaces, these should be documented and linked or cross-referenced to the source in an interface register so that the associated potential risks can be managed. Meetings should be arranged to define and detail each of the interfaces, together ‘with the respective ‘owners’ of the interfaces. (2 State of NSW through Transpod for NSW Page 11 of 2674.2 1310507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 ‘An interface register should provide @ record of all physical, functional and information interfaces, both internal and extemal, The register should contain enough detail to ensure that all interfaces are identified comprehensively. The register should provide details of each interface, including its boundaries, detailed description, actions against the interface, and an ‘open or closed! status to identiy if t has been fully reviewed and managed to completion. The register also includes a ‘required by date' to identify when actions associated with @ particular interface, or when provision of interface information, must be completed. The type of tool used to record and manage these interfaces should be tallored to the needs of the project. For low complexity projects, a spreadsheet may suffice. For complex projects with many stakeholders, a database or specialist tool may be @ more suitable ‘The interface register should be updated regularly. The interface register is issued in configured baseline releases, either periodically or when specifically required in the system life cycle. ‘The interface register typically includes the following fields + [Link] alphanumeric code which identifies the two systems being interfaced + aserial number that uniquely identifies every interface + a description of the interface + the interfacing organisations and their responsible subgroups + the party responsible for leading the definition and management of the interface + planned and actual dates for the definition phase "planned and actual dates for the resolution phase * an indication of whether or not the interface is safety critical. If yes, the interface will be subject to further safety and systems assurance processes. «the current status of the interface (identification, definition, resolution or closed) = progress status (on time or late) = issue number and date at which the interface register was last updated, ‘An example of an interface register is showin in Appendix A Interface control document ‘An interface control document (ICD) describes the interfaces between internal elements or between systems. They are alternatively referred to as interface control specifications (ICS) ICDs are used to manage the definition and control of the interfaces of a system and its elements. The design of systems solutions are thereby bound by ICD requirements, Each ICD should communicate all possible inputs to, and all potential outputs from, a system to the potential or actual user of the system. (2 State of NSW through Transpod for NSW Page 12.01 2675 18 10607: 2013 ‘AZO Guide to Systems tegration Version 1.0 Effective Date: 30 August 2013 ‘An ICD should be prepared for systems and elements that have a large number of detailed components are significantly complex, or where the level of information required is greater than can be recorded by a simple interface register. For interfaces between systems and elements of low complexity, it may be appropriate to provide full details of the relevant interface within the interface register, without the need for @ separate ICD. ‘An ICD can be @ drawing or a document that depicts an interface in as much detail as is necessary to bind the scope of requirements on either side of that interface. It should only describe the interface itself, not the characteristics of the systems or external environment, that, meet at that interface, ‘An ICD should be a 'Iiving document’ which is reviewed and updated on an ongoing basis until agreed and signed off. All potential changes to the interface should be discussed with all interested or affected stakeholders, and any changes to interfaces or the introduction of new interfaces must be reflected in interface control documents, ‘When the definition of the interface is finalised and agreed, all the interface stakeholders should sign off on the ICD. Each ICD should be developed with input and agreement from all interfacing stakeholders, but only one stakeholder can own and be accountable for the ICD document. ‘The structure and content of an example interface control document is shown in Appendix B. Reviewing interfaces ‘An interface review is a formal meeting held between interested stakeholders and affected design teams on a mutti-disciplinary project. It may sometimes be combined with an interdisciplinary design review. An interface review is performed to ensure that all aspects of one or mote selected interfaces are considered and discussed, and decisions recorded. The interface review meeting is the place to discuss and resolve all interface problems. The review may also result in the identification of new interfaces, or identify new properties or issues associated with interfaces already captured, Incorporating interface design into ongoing regular design team coordination meetings, where all affected disciplines are present to identify, define and agree on the developing interface designs, is considered best practice. Interface hazard analysis workshops ere performed to identify and manage interface hazards and associated safely risks, Further details of these workshops can be found in TS 20001 ‘System Safely Standard for New or Altered Assets. Interdisciplinary design review process ‘An interdisciplinary design review is a specific check that the design has been thoroughly analysed and defined, including all inter-system and intra-system interfaces. interdisciplinary design reviews are also known as interdisciplinery design checks. (2 State of NSW through Transpod for NSW Page 13.1269.1 9.2 18 10607: 2013 ‘AZO Guide to Systems tegration Version 1.0 Effective Date: 30 August 2013 Formal interdisoiplinary design reviews that provide assurance to stakeholders that the interfacing systems and elements are compatible should be performed for all inter-system and intra-system interfaces. An interdisciplinary design review should be held prior to project gateways, milestones and deliverables, As a minimum they should be held during both the concept and development design stages, The reviews should be held sulficiently in advance so that any actions emerging from the review, including design revisions, can be completed in sufficient time to enable the project milestone to be achieved, All system elements and interfaces should be represented in the interdisciplinary design review process. As a minimum, the design manager and the discipline or system element leads should participate. It may be appropriate for other project team members to attend to ensure the review addresses all necessary areas, Other members may inclide the interface manager, project manager, safety manager and environmental manager. ‘The design manager should prepare an agenda and circulate it to attendees. All documents and drawings to be reviewed should be circulated and reviewed prior to the meeting, All documents and drawings should also be presented at the meeting, All comments, issues, conflicts, and resolutions should be recorded on an interdisciplinary design review record sheet The interdisciplinary design review process is shown in Appendix D. Systems integration ‘Systems integration is the assembly of component elements into one system, and ensuring that all elements function together as @ coherent system. Purpose of systems integration ‘The standerd ISO/IEC 15288:2008 states: “The purpose of the Integration Process is to assemble a system that is consistent with the architectural design. This process combines system elements to form complete or partial system configurations in order to create @ product specified in the system requirements Systems integration as defined in ISO/IEC 15288:2008 deals specifically with the assembly of the implemented elements, and verification of the system against its properties as designed Systems integration activities ‘Systems integration is performed on the system and its elements, and on the system and its external interfacing systems, The objective is to ensure that elements are integrated into the system and that the system is fully integrated into the wider environment, (2 State of NSW through Transpod for NSW Page 14 of 269.2.1 9.2.2 9.3 1310507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 ‘Systems integration activities should include planning and performing systems integration. The output of systems integration activities should be formally documented and recorded as configured evidence, because it forms part of the evidence supporting systems and safety assurance. Details on requirements traceability and systems architecture are covered in the ASA guidance documents TS 10505 AEO Guide to Requirements Definition and Analysis, and TS 10508 AEO Guide to Systems Architectural Design respectively. Plan systems integration The first systems integration activity is the definition of the systems integration plan. This inoludes the integration sequence, which is a series of progressive integration levels through to the complete system integration. It includes details of any testing tools or facilities that need to be used or coordinated Perform systems integration The following activities should be performed = assemble the system elements according to the systems integration plan = confirm that the system elements have been verified and validated against the specified acceptance criteria * verify and validate that the system elements have been interfaced correctly in accordance with the applicable interface documents, e.g. interface control descriptions. Confirm the correct flow of information across internal and external interfaces at each level of assembly. See Section 7.42 Interface control document. * verify and validate that the system elements have been assembled correctly. Confirm correct functionality of assembled products through integration testing and analysis at each successive level of assembly. + document the integration testing and analysis results, including any non-compliances and remedial actions, Document and control the architectural baseline including any modifications. Systems integration outputs The output of the systems integration process is expected to be a fully integrated system that meets all the stakeholder and user requirements. The following evidence and outputs of the systems integration activities should be recorded! = systems integration plan = systems integration enabling requirements © ary constraints arising from the integration strategy (2 State of NSW through Transpod for NSW Page 15 of 241310507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 integrated system interface control documents interdiscipinary design review records system integration report The specific evidence that an organisation needs to demonstrate its systems integration processes will depend on the scope and nature of the work provided to TINSW, including the level of safety risk management required. For this reason, this document only provides an overview of the processes that AEOs need to demonstrate. tt does not outine the evidence that an AEO should produce in order to be authorised to perform systems engineering for TINSW. 10. Roles and responsibilities ‘The principle roles involved in systems integration, interdisciplinary design reviews and interface menagement include the following: systems integrator Interface manager or engineer design manager element design lead users, installers and inspectors 10.1 Systems integrator The systems integrators role encompasses the following activities: develop the systems integration strategy and program lead the implementation of the systems integration strategy provide high level support of the interface management process: formally approve the interface management plan ‘champion the interdisciplinary design review process assure systems integration and interface management success in line with the project programme ‘communicate any systems integration and interface issues to the client and other interested external parties (2 State of NSW through Transpod for NSW Page 18 of 261310507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 10.2 Interface manager The interface manager's role encompasses the following activities, * create and maintain the interface management plan. * create and maintain the “live interface register + produce the interface control document template + facilitate regular interface meetings + establish and document reviews of the interface register = maintain the interface menagement program 10.3 Design manager The design managers role encompasses the following activities: * ensure that interface requirements are developed within the project system and element designs ensure that interface control documents are produced where required = ensure the commitment of the design team to interface management + provide input into the interdisciplinary design review process 10.4 Element de: The element design lead's role encompasses the following activities in lead * detail all interfaces relevant to their elements: = collect relevant information from internal and external parties to enable element specific interfaces to be fully defined and managed + provide information to the Interface Manager for regular reviews of the interface register + attend interface meetings as required + ensure adherence to this process and taking full esponsibllly for their element interfaces © delegate a responsible person for each interface 11. Records Systems integration including interface management is typically be supported by @ number of records, These records include: + interface specifications * interface management plan (2 State of NSW through Transpod for NSW Page 17 of 241310507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 + interdisciplinary design review records + integration test plan * integration test specifications + integration test reports = Updated requirements verification and traceebility matrix 12. Railway station example The following example of a railway station identfies the typical assembly of elements and systems into 2 combined system of interest. Individual elements combine to form systems, which themselves combine to form a system of systems, Each element firstly needs to be individually integrated to operate as a stand alone element, The next step is to integrate each element into systems, for example the fire hydrants, fire alarms and fire control panel should be integrated together to deliver the fire control system. The final step is to integrate each system into the wider railway station system, to ensure that all the elements and systems function together as a coherent overall railway station system. The overall railway station system can only be available for entry into operation when all elements and systems have been successfully integrated into the overall railway station systern, and verification and validation of the overall railway station system has been completed, (2 State of NSW through Transpod for NSW Page 18 of 26Ts 10507: 2013 ‘AGO Guide to Systems integration version 1.0 Effective Date: 30 August 2013 System of Systems Railway Station ‘Systems Passenger Ticketing 9 Splen Information Elements Fire | |_| Electronic Static hydrants gates signage Fire Booking Platform alarm offs indicator machines Fire Ticket Public control | f-} vending ' panel machines | address Ae canbe et eee cata Other Other elements he Figure 2 - Example of systems integration application — railway station {State of NSW through Transpott for NSW Page 19 of 24Appendix A - Example interface register ‘Table 1 Example interface register 90 cle ere ey ‘Ret [Interface Type [interface Date Toterface Boundary Description of | Aaions and | Taceabilly [Provider | Receiver | Date ‘satus Wain | Su AB | Mees rem vin [To Interface Comments Reauired ‘00006 | Physical [intemal [PLC /ScanA | eriaz00s |ccTV | Emeime& [SCADA [+ Operator | Capnuem | SCADAand [IT Team | IT Team Open Netiorks Sib. Ethemet |" contoland |" Tesscapa |” PL atom Network | montoinget | ana PLE Neto rte Sut theceny Networks con Sub Stbeysen | CCV Sub | System SOS + Astoratie ‘gptem SOS |. ScADAand Sutchngot | sa SWDS. |" pic. Camerasio | + Captuetinkon | Neteots Aion Menor |" SCADA Con Sub. and Air Functional Stern Bvwten Bick ‘wos recep of Bagram |. Scapa Ar (fom Functor sites a ey network fd Dagan, equipment. ‘050072 | Funetenal [intemal CCTV | SCADA | Caoerzo0e DEV | CCTV | SCADA |= Faaure + Dosamentin [+ COTVERD, | iTTeam | FT Team Open Sub | Wortstaten |" detestion of |” CCTVSRO' | Scapa SRD system Seve + Doeamentin | Lc SCADASRD |" Networks + Dozamentin | SRO PLONetete |. Ios (cory SRO. nd SCADA) + Documentin ics. ‘DOOIED | Physical | Exteral | Normal Handset 21/07/2010 | WIBBOLV | Sructred| Nomal | Swkcroom | Installagon Reqiredsy | TTeam | ca) ‘Open Sito. | caling™ | Campus | Telephone to Stakehoise ‘or Normal Campus ‘DOOGES | Physical | Etemal | Nonmal Handset | ZWVOTIOIO | WIBBOV! | Secured] Noma | Swke-oom | hetallavon Requredby | TTeam | cB) Open LvSwieh | caling™ | Campus | Telephone to Stakehoise ror Normal Campus ‘00477 | Funetenal | Etemal TOM Handset | 2170772010 | Emergency | Skucwred| TOM | Emergency | Gonfguraton | IT Voice Trea | Br ‘Open Phone 26” | eating | Campus | Taephone to Production Ton Design ‘50478 | Funetenal | Extemal TOW Handset 1/072010 | Emergency | Sruetred | TDW Contgwaton | rVaice ream | car ‘Open Prone 27” | eating | Campus Production Design ‘HOUT | formation |Etemal COTY | SSTP | ca/o6008 ‘Arpor Security cow | ssrP Open anager approval reeswed backto theroject ‘DHOUTE | ormaton | Eemal | COTW | Fre | OOOBTI005 7 Fie alam cal | Coptured on Frei Teare Open ‘System Pohntlocaions |" CCTV Hooke ‘ystems Tobecovered | up Regster Tear by objec: te NH ag Tanga1310507; 2013 ‘AGO Guide to Systems Integration Version 1.0 Effective Date: 30 August 2013 Appendix B - Example interface control document Atypical example of the structure and content of an interface control document is shown below. Cover sheet interface ttle subsystem A subsystem B Interface control document (ICD) number revision approvals date last updated ‘quality information - author, reviewer, approver revision history Interface summary interface summary description, scope and status reference list abbreviations and definitions Interface detail (2 State of NSW through Transpod for NSW Pa interface ttle introduction - a short description of the interface covered by the document purpose of document - what interface parameters need to be defined and resolved in the IcD interface functional description - the functional requirement of the interface interface technical description - all technical aspects of the interface necessary to fulfil stated purpose of the ICD configuration and demarcation points - identify the configuration of the interface along with the demarcation points of each partner's works ‘scope of work - define each interface partner's scope of work up to the demarcation point interface class. interfacing entities Interface type 21 0626Ts 10507: 2013 ‘AGO Guide to Systems Integration Effective Date requirement source intent safety critical detalls assumptions, dependencies, constraints tisks interface owner declaration Interface management arrangements documentation and communications ata and configuration management Tequirements and assumetions, dependencies and constraints management Tisk and issues management hazard management Interface technical aspects Interface technical aspects should include one or more of the following key performance data spatial requirements weights mounting or fixing requirements access requirements electrical load heat dissipation environmental requirements control interfaces, data communication requirements electromagnetic compatibility requirements {State of NSW through Transpos for NSW Version 1.0 30 August 2013, Page 22 0f 241310507; 2013 ‘AGO Guide to Systems Integration Version 1.0 Effective Date: 30 August 2013 Appendix C - Example interface management plan An interface management plan could include the following contents: Introduotion Objectives: ‘Assumptions, dependencies and constraints ‘Scope and application References and standards ‘Abbreviations and definitions Roles and responsibilities + Interface manager © (Safety) risk manager + Interface owner Interface management process «Interface identification + Interface architecture = Interface control + Interface programme + Interface spectfication + interface design and implementation Interface control + Traceability + Configuration management Interface deliverables Interface (management) register «Interface control documents * Interface requirements specifications (© State of NSW through Transpot for NSW Pa 2301248 10607: 2013 ‘AEO Guide to Systems integration Version 0 tecive Date 20 August 2019 Appendix D — Interdisciplinary design review process Responsibility Process Notes Orgran w opr an snd bth pends and crear fo] co names an see coer trovew fa f= "tment scsnc nina icon “sori the croramrteere he OR nrishon or rete -— tee! ouchnar reer esgnsccorensonicronge age of = siete esis BR eeddah e pdt erly scone ote whe {DR workop ial Oia ireegoii er nena al Sefer thine rrp gl roma: F-—}-—} sant essa esate oy sues Retaten PAE] Moco atuncees. Yom papas wh caus ‘ritens coments shuld ie onoed onthe DR rood ‘ed Be weakep ate omit Pe On ayoren ata opts tam DR cones have Te set OR ond hull ude £eeiean{—J PP] stecsupe tse it ncctdconiming tr shconmartsranea [AS “] — proccontas cen lowes Sqrares canbe we ele edarede bay cay iodo the et are cane Bee pp | ove stinerin nm ta Figure 3 Interdisciplinary design review process Page 24.26 £2 State of NSW through Transport for NSW