A Project Document of the Advanced Transportation Controller Joint Committee. APIVS SRS v02.03

Transcription

1 A Project Document of the Advanced Transportation Controller Joint Committee Advanced Transportation Controller (ATC) Application Programming Interface (API) Validation Suite (APIVS) Software Requirements Specification (SRS) November 20, 2014 ConOps in support of: USDOT Work Order , Tasks 7-8 For approval by: For use by: Members of the API Working Group Siva Narla, Chief Engineer and ITS Standards Manager Institute of Transportation Engineers George Chen and Douglas Tarico, Co-Chairs ATC API Working Group Ralph W. Boaz, Project Manager and Systems Engineer ATC API Validation Suite Project Members of the ATC API Working Group Consulting Team for the ATC API Reference Implementation Project Prepared by: Ralph W. Boaz, Project Manager and Systems Engineer Copyright 2014 AASHTO/ITE/NEMA. All rights reserved. APIVSSRS0203_141120a.docx Page 1 of 20

2 CHANGE HISTORY DATE NOTE 05/13/10 Initial Draft WGD Version /21/10 Version includes changes from API WG Telecon 05/21/10. 06/17/14 Version Update for the API Reference Implementation Project. 07/16/14 Version Update per the API WG Walkthrough 06/26/14 and 07/01/14. 07/25/14 Version Update per the API WG Teleconference 07/23/14. 11/20/14 Version Updates for USDOT approved re-scope of the project which provides for a fixtureless test environment. APIVSSRS0203_141120a.docx Page 2 of 20

3 NOTICE Joint NEMA, AASHTO and ITE Copyright and Intelligent Transportation Systems (ITS) Working Group These materials are delivered "AS IS" without any warranties as to their use or performance. AASHTO/ITE/NEMA AND THEIR SUPPLIERS DO NOT WARRANT THE PERFORMANCE OR RESULTS YOU MAY OBTAIN BY USING THESE MATERIALS. AASHTO/ITE/NEMA AND THEIR SUPPLIERS MAKE NO WARRANTIES, EXPRESSED OR IMPLIED, AS TO NON-INFRINGEMENT OF THIRD PARTY RIGHTS, MERCHANTABILITY, OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL AASHTO, ITE, NEMA, OR THEIR SUPPLIERS BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY CLAIM OR FOR ANY CONSEQUENTIAL, INCIDENTAL, OR SPECIAL DAMAGES, INCLUDING ANY LOST PROFITS OR LOST SAVINGS ARISING FROM YOUR REPRODUCTION OR USE OF THESE MATERIALS, EVEN IF AN AASHTO, ITE, OR NEMA REPRESENTATIVE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Some states or jurisdictions do not allow the exclusion or limitation of incidental, consequential, or special damages, or exclusion of implied warranties, so the above limitations may not apply to you. Use of these materials does not constitute an endorsement or affiliation by or between AASHTO, ITE, or NEMA and you, your company, or your products and services. If you are not willing to accept the foregoing restrictions, you should immediately return these materials. ATC is a trademark of NEMA/AASHTO/ITE. APIVSSRS0203_141120a.docx Page 3 of 20

4 CONTENTS 1 INTRODUCTION Purpose Scope Definitions, Acronyms and Abbreviations References Document Organization OVERALL DESCRIPTION Product Perspective Product Functions User Characteristics Constraints Assumptions Apportioning of Requirements SPECIFIC REQUIREMENTS No Cost Distribution Open Source ITE Approved Software License Unrestricted Use by Users Redistribution of Modified Source Code No Cost Redistributed APIVS Source Code ing Environment C Programming Language Source Code Quality XML Scripting Language Interpreted Scripts Run All s Run Selected s Continuous Loop Conformance Indication Nonconformance Indication Detailed Log Summary Result Output Options XML Output Files Front Panel User Interface (FPUI) Library ing Field I/O (FIO) Library ing Time of Day (TOD) Library ing Multiple and Concurrent Applications APPENDICES Appendix A: Needs-to-Requirements Traceability Matrix (NRTM) APIVSSRS0203_141120a.docx Page 4 of 20

5 1 INTRODUCTION This Software Requirements Specification (SRS) is for the test software referred to as the Advanced Transportation Controller (ATC) Application Programming Interface (API) Validation Suite (APIVS) software. It is being developed as part of the Reference Implementation of ATC 5401 Application Programming Interface (API) Standard Version 2 project funded by the USDOT Contract Number DTFH61-11-D-00052, Work Order T (referred to as the APIRI project). This section provides an introduction for the including subsections on Purpose; Scope; Definitions, Acronyms, and Abbreviations; References; and Overview. 1.1 Purpose This SRS establishes the requirements for software that will be used to test and validate that the APIRI software being developed as part of the APIRI project conforms to the ATC 5401 Standard (see Section 1.4 References). It also serves as a foundation for developing a Software Design Description (SDD, see Section 1.4). The SRS provides a common understanding of the APIVS software requirements for: a) The USDOT Intelligent Transportation Systems (ITS) Joint Program Office (JPO) who is sponsoring the work and requires the use of a formal software development process; b) The consulting team contracted to develop the software described; c) The consultants, manufacturers, and public transportation professionals who participate in the API Working Group (WG) who provide domain expertise, quality assurance, testing assistance and ultimately the maintenance of the software; and d) The transportation industry as a whole that will depend upon this software to test implementations of the ATC 5401 Standard resident on ATC units. 1.2 Scope This SRS establishes the requirements of the APIVS software based on the user needs identified in the APIVS Concept of Operations (ConOps) (see Section 1.4). The purpose for this software is to test the APIRI software that is being developed as part of the APIRI project. The APIVS is not intended to test any other aspect of the ATC unit such as memory, CPU performance, the Linux environment, or application programs. Some of the benefits of the APIVS include: a) Impartial testing common to the entire industry; b) Greater user confidence and faster market penetration of ATC units with APIRI software as manufacturers have a means to prove conformance to the ATC 5401 Standard; c) A tool for agencies to reference in their procurement processes and specifications; d) Increased reliability of ATC units with APIRI software; e) Increased portability and interoperability of application programs on ATC units; and f) A common source code for test software that can be expanded or enhanced when a new version of the ATC 5401 Standard is produced. 1.3 Definitions, Acronyms and Abbreviations Term AASHTO API Definition American Association of State Highway and Transportation Officials Application Programming Interface APIVSSRS0203_141120a.docx Page 5 of 20

6 Term API Utilities APIRI Software APIRI Project APIVS Software Application Program ATC ATC Device Drivers BOM Board Support Package BSP ConOps CPU Device Driver FIO FPUI H/W I/O IEC IEEE ISO ITE ITS JC Definition API software that is used for setting system-wide purposes on an ATC controller unit. API Reference Implementation (software). API software developed as part of the ATC APIRI Project. Entire project managed by ATC APIRI PMP v01.01 Project Management Plan (PMP) for the Advanced Transportation Controller (ATC) Application Programming Interface (API) Reference Implementation Project including software, hardware and documentation. API Validation Suite Software Any program designed to perform a specific function directly for the user or, in some cases, for another application program. Examples of application programs include word processors, database programs, Web browsers and traffic control programs. Application programs use the services of a computer's O/S and other supporting programs such as an application programming interface. Advanced Transportation Controller Low-level software not included in a typical Linux distribution that is necessary for ATC-specific devices to operate in a Linux O/S environment. Bill of Materials. A list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts and the quantities of each needed to manufacture an end product. Software usually provided by processor board manufacturers which provides a consistent software interface for the unique architecture of the board. In the case of the ATC, the Board Support Package also includes the O/S See Board Support Package Concept of Operations Central Processing Unit. A programmable logic device that performs the instruction, logic and mathematical processing in a computer. A software routine that links a peripheral device to the operating system. It acts like a translator between a device and the application programs that use it. Field Input and Output Front Panel User Interface Hardware Input/Output International Electrotechnical Commission Institute of Electrical and Electronics Engineers International Organization for Standardization Institute of Transportation Engineers Intelligent Transportation Systems Joint Committee APIVSSRS0203_141120a.docx Page 6 of 20

7 Term JPO Linux Linux Kernel Loopback Driver Mechanical Drawing N/A Operational User O/S PCB PMP RI RTC SDD SDO Schematic Diagram SE Software Validation SOW SRS S/W TBD er TFCS TOD Definition Joint Program Office Low-level software that is freely available in the Linux community for use with common hardware components operating in a standard fashion. The Unix-like operating system kernel that was begun by Linus Torvalds in The Linux Kernel provides general O/S functionality. This includes functions for things typical in any computer system such as file I/O, serial I/O, interprocess communication and process scheduling. It also includes Linux utility functions necessary to run programs such as shell scripts and console commands. It is generally available as open source (free to the public). The Linux Kernel referenced in this standard is defined in the ATC Controller Standard Section 4.3.5, Appendix A and Appendix B. A virtual device driver that loops back the output ports to a device to the input ports from a device without actually going to through the physical device. A drawing to scale of a machine, machine component, or device from which dimensions can be taken for manufacturing. Not Applicable A technician or transportation engineer who uses the controller to perform its operational tasks. Operating System Printed Circuit Board Project Management Plan Reference Implementation Real-Time Clock Software Design Document or Software Design Description Standards Development Organization A diagram which shows, by means of graphic symbols, the electrical connections and functions of a specific circuit arrangement. Systems Engineer The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. Statement of Work Software Requirements Specification Software To Be Determined A user developer, test engineer or test technician capable of operating the API Validation Suite described by this document. Transportation Field Cabinet System Time of Day APIVSSRS0203_141120a.docx Page 7 of 20

8 Term TOPR US USDOT XML User Developer Walkthrough WG Definition Task Order Proposal Request United States United States Department of Transportation Extensible Markup Language A software developer that designs and develops programs for controllers. A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content. Working Group 1.4 References The documents referenced in this SRS are listed below. Institute of Electrical and Electronics Engineers, IEEE Std , IEEE Recommended Practice for Software Requirements Specifications. IEEE, Institute of Electrical and Electronics Engineers, IEEE Std , IEEE Recommended Practice for Software Design Descriptions. IEEE, Institute of Transportation Engineers, API Reference Implementation Project Open Source Software (OSS) Concept Paper. Institute of Transportation Engineers, 12 June Institute of Transportation Engineers, Advanced Transportation Controller (ATC) Application Programming Interface (API) Validation Suite (APIVS) Concept of Operations (ConOps) v ATC Joint Committee, 20 November Institute of Transportation Engineers, ATC 5401 Application Programming Interface (API) Standard for the Advanced Transportation Controller (ATC) v02. ATC Joint Committee, 15 September Institute of Transportation Engineers, ATC APIRI PMP v01.02 Project Management Plan (PMP) for the Advanced Transportation Controller (ATC) Application Programming Interface (API) Reference Implementation Project. ATC Joint Committee, 5 November Institute of Transportation Engineers, Intelligent Transportation System (ITS) Standard Specification for Roadside Cabinets v b. ATC Joint Committee, 16 November Institute of Transportation Engineers, User Comment Draft ATC 5201 Advanced Transportation Controller (ATC) Standard Version ATC Joint Committee, 30 July APIVSSRS0203_141120a.docx Page 8 of 20

9 International Organization for Standardization, ISO/IEC 9899:2011 Programming Language C. ISO, 8 December National Electrical Manufacturers Association, NEMA Standards Publication TS v02.06 Traffic Controller Assemblies with NTCIP Requirements. NEMA, United States Department of Transportation. Task Order Proposal Request (TOPR) Task Order # T , Reference Implementation of ATC 5401 Application Programming Interface (API) Standard Version 2 (ATC 5401 v02) ITE Support. USDOT, 1 July Document Organization The organization of this SRS is based on IEEE Std , IEEE Recommended Practice for Software Requirements Specifications (see Section 1.4). It made up of four sections and appendices. Section 1, Introduction, provides an overview of the entire document. Section 2, Overall Description, provides background information necessary to establish the context for the requirements. Section 3, Specific Requirements, establishes the requirements that must be satisfied by the APIVS software. Appendix A contains traceability matrix showing the relationship of user needs established in the APIVS ConOps to the requirements in this SRS. 2 OVERALL DESCRIPTION This section describes the general factors that affect the APIVS and its requirements. It includes subsections on Product Perspective; Product Features; User Characteristics; Constraints; Assumptions and Dependencies; and Apportioning of Requirements. The terms function or functions used in this section refer to software functions or software function calls. If a general functionality or capability is intended, an effort was made to use other terms. 2.1 Product Perspective The Advanced Transportation Controller (ATC) standards program has been developed to meet the current and future needs for transportation field equipment. The goals of the program are to provide for transportation field equipment that is open architecture, modular, multi-process, multi-application, can grow with technology and can be used to upgrade existing transportation field cabinet systems (TFCSs). At the heart of this program are the ATC 5201 Advanced Transportation Controller Standard and the ATC 5401 Application Programming Interface Standard. ATC 5201 specifies a controller architecture where the computational components reside on a single (5 x 4 ) printed circuit board (PCB), called the Engine Board, with standardized connectors and pinout. It is made up of a central processing unit (CPU), a Linux operating system (O/S) and device drivers, memory, external and internal interfaces, and other associated hardware necessary to create an embedded transportation computing platform. ATC 5401 defines both user interface facilities and C programming language interfaces for ATC units that are not provided through ATC 5201 or the standard Linux O/S. The user interface facilities of ATC 5401 include a windowing system that allows operational users to interact with concurrently operating application programs (which in turn have their own user interfaces) and system-wide configuration management utilities. The C programming language interfaces of ATC 5401 provide C language function definitions that allow software developers to create application programs that share resources of the ATC unit including the front panel, field input/output (I/O) devices and real-time clock. When used with the Linux O/S and device drivers of the Engine Board, ATC 5401 provides for a software environment that allows application programs to be portable (runs on any ATC manufacturer s equipment), compatible (will run concurrently with other application programs), and interchangeable (assuming they perform the same function) on a single ATC unit. APIVSSRS0203_141120a.docx Page 9 of 20

10 Figure 1 illustrates the layered architecture of the ATC software. The Linux O/S and Device Drivers reflects a specification of the Linux operating system defined in the ATC Board Support Package (BSP) (see ATC 5201 Standard, Appendix A and Appendix B). This includes functions for things typical in any computer system such as file I/O, serial I/O, interprocess communication and process scheduling. It also includes the specification of the device drivers necessary for the Linux O/S to operate on the ATC hardware. API S/W refers to software defined by the ATC 5401 Standard. Within the context of the APIRI project, the APIRI software being developed is the API software in the picture. As shown in Figure 1, user developers, operational users and application programs use the API software to interface to ATC units. User Developer Operational User USERS Interface and Behavior Defined By ATC 5401 Standard Hardware and O/S Defined By ATC 5201 Standard API Software Application Software Linux Operating System and Device Drivers APPLICATION LAYER API SOFTWARE LAYER ATC BOARD SUPPORT PACKAGE LAYER HARDWARE LAYER Figure 1. Layered organization of ATC software. In order to perform a consistent software validation of an API software implementation, the software under test must be isolated (to the extent possible) from other software or systems that may unpredictably influence its operation. The Engine Board based architecture specified in the ATC 5201 standard is ideal for this purpose by isolating the computational components and the software environment of the controller unit from other components of the controller unit. The APIVS test environment proposed is shown in Figure 2. It consists of an ATC unit and a personal computer (PC). The PC interface is necessary to load test software, initiate tests, and extract results. It is possible that the PC can also serve in the operation of some tests. Details of the operation of the test environment and tests are to be documented according to a test plan. APIVSSRS0203_141120a.docx Page 10 of 20

11 CONSOLE CABLE ATC Figure 2. API test environment uses a personal computer connected to the console port of the controller. The layered software environment for the APIVS software is similar to the layered organization of the ATC software (see Figure 3). The APIVS takes the place of the Application Software in Figure 1. The user is now a er which may be a User Developer, Engineer or Technician. The APIVS resident on the Engine Board exercises the API software and records results. Special device drivers are necessary for the APIVS to perform testing without requiring the physical connectors on the controller unit. er USERS API Validation Suite API Software APIVS Loopback Drivers LINUX O/S & Device Drivers APPLICATION LAYER API SOFTWARE LAYER ATC BOARD SUPPORT PACKAGE LAYER HARDWARE LAYER Figure 3. The layered software environment for the APIVS System Interfaces The test environment described in Section 2.1 and the APIVS is self-contained. There are no other system interfaces necessary User Interfaces APIVSSRS0203_141120a.docx Page 11 of 20

12 A PC running a HyperTerminal program may serve as a console in the operation of some tests. The intent of the APIVS is to limit human interaction during the test. Any specific user needs for user interfaces are identified in Section Hardware Interfaces The only physical interface is the connection of the PC and the ATC unit as identified in Section Software Interfaces The APIVS will operate on the ATC Engine Board utilizing standard Linux interprocess communications as is determined necessary by the contractor. The APIVS will interface to the Engine Board via the API Software and the Linux environment defined in the ATC 5201 Standard Communications Interfaces A serial or Ethernet connection may be used between the PC and the ATC unit to load the APIVS, initiate tests, and extract results. This is already provided through the Linux environment of the Engine Board and the serial and Ethernet connectors on the ATC unit Memory The APIVS must be able to operate on a controller unit with memory limits described in the ATC 5401 Standard Operations There are no additional operational needs. 2.2 Product Functions The major product functions of the APIVS software are as follows: Configuration. This product function of the software provides for the selection of tests to be performed and any user selectable options. Execution. This product function executes the tests that exercise the API software. TFCS Response. This product function responds to the execution of the API software in a fashion representative of an ATC unit in a transportation field cabinet system (TFCS). This simulation of the TFCS environment needs to be at a level sufficient for the purposes of testing and is not meant to be a complete cabinet simulator. [Guidance: Flat files that contain the messaging that needs to be used in a test is suggested.] Results. This product function provides the results of the tests that were executed. 2.3 User Characteristics A user developer, test engineer or test technician capable of operating the API Validation Suite described by this document. 1) Windows operating systems; 2) Understands the organization and use of the Windows file system; 3) Able to use communications services Telnet and FTP; APIVSSRS0203_141120a.docx Page 12 of 20

13 4) Experienced handling electronic equipment, circuit boards and cabling; 5) Able to follow detailed test steps and procedures; and 6) Capable of keeping careful records and organizing test results. Additional attributes of the user may include: 1) Ability to generate test scenarios, test cases and write test scripts and 2) Software development skills such as Ability to design, construct, test, and maintain the software systems; Understands the processes and steps to compile, link and load software for embedded systems; Proficient at writing software in the C programming language; and Experienced with the Linux Operating System. 2.4 Constraints The following operational policies and constraints have been identified: a) Portions of the APIVS software will be resident on an ATC Engine Board with operational API software. These portions will need to be compatible with the Board Support Package as defined by the ATC 5201 Standard. b) Since ATC Engine Boards may have been implemented using a variety of processors, the APIVS software that is to be resident on the Engine Board will need to be compiled, linked and loaded in a manner compatible with the processor on the Engine Board. 2.5 Assumptions The APIVS software tests conformance of API software to the ATC 5401 Standard. If this standard is modified, the APIVS software will have to be updated accordingly. 2.6 Apportioning of Requirements There are no requirements apportioned as of the date of this SRS. 3 SPECIFIC REQUIREMENTS This section defines the requirements for the APIVS. Each requirement is listed with a separate paragraph number and included in a traceability matrix in Appendix A. The terms function or functions used in this section refer to software functions or software function calls. If a general functionality or capability is intended other terms were used. 3.1 No Cost Distribution The APIVS software shall not have any content or component that requires a fee for the distribution of its source code and documentation. 3.2 Open Source The APIVS software shall be available to anyone through an Open Source Software (OSS) environment consistent with the USDOT approved API Reference Implementation Project Open Source Concept Paper (see Section 1.4). APIVSSRS0203_141120a.docx Page 13 of 20

14 3.3 ITE Approved Software License The APIVS software shall have all source code distributed using a software license that is approved by ITE. 3.4 Unrestricted Use by Users The APIVS software shall have a license that allows for unrestricted use by the software by users. 3.5 Redistribution of Modified Source Code All APIVS software source code shall be available under open source licensing terms (Gnu Public License) which require modifications and derived works to be distributed under the same terms. 3.6 No Cost Redistributed APIVS Source Code The APIVS software shall have a license that requires redistributed APIVS source code to be at no cost to users. 3.7 ing Environment The APIVS software shall be operational within the test environment and testing approach described in Section C Programming Language The APIVS software shall be written using the C programming language as described by ISO/IEC 9899:2011 (see Section 1.4). 3.9 Source Code Quality The APIVS software shall be written in a fashion consistent with the GNU Coding Standards (see Section 1.4) XML Scripting Language The APIVS software shall use an XML (Extensible Markup Language) based scripting language to define tests Interpreted Scripts The APIVS software shall execute XML defined tests without recompilation of the APIVS software Run All s The APIVS software shall have a user option to run all of the tests available in the test suite Run Selected s The APIVS software shall have a user option to run a selected subset of the tests that are available in the test suite. APIVSSRS0203_141120a.docx Page 14 of 20

15 3.14 Continuous Loop The APIVS software shall have a user option to run selected subsets of tests in the test suite sequentially in a continuous loop Conformance Indication The APIVS software shall return a value of 0 when a set of tests selected from tests available in the test suite are found to conform to the ATC 5401 Standard Nonconformance Indication The APIVS software shall return value of -1 when a set of tests selected from tests available in the test suite are found not to conform to the ATC 5401 Standard Detailed Log The APIVS software shall have a user option to produce a detailed log of the tests performed including: The library, function and arguments on an API function call and the return values; If a function fails, guidance to the user on the cause of the failure; The test being executed; Line # in the APIVS source code; Step in the test; and Time stamps for each step in the test Summary Result The APIVS software shall have a summary result that lists each test performed and the conformance/nonconformance result Output Options The APIVS software shall have output options as follows: a) Conformance/nonconformance Indication only; b) Conformance/nonconformance indication and summary result; and c) Conformance/nonconformance indication, summary result and all logs and traces XML Output Files The APIVS software shall output any summary, log or traces into a file in an XML format Front Panel User Interface (FPUI) Library ing FPUI Library C Function Present The APIVS software shall validate that each FPUI function defined in Section 4.1 of the ATC 5401 Standard is present in the API software FPUI Library C Function Conforming Arguments The APIVS software shall validate that each FPUI function has the correct arguments as defined in Section 4.1 of the ATC 5401 Standard. APIVSSRS0203_141120a.docx Page 15 of 20

16 FPUI Library C Function Error Checking The APIVS software shall validate that each FPUI function returns the correct error codes for the error conditions defined in Section 4.1 of the ATC 5401 Standard FPUI Library C Function Argument Boundary Checking The APIVS software shall validate that the boundaries of the arguments to the FPUI functions operate as defined in Section 4.1 of the ATC 5401 Standard FPUI Library Composite ing The APIVS software shall validate that each FPUI function operates correctly under typical operating conditions with other API functions using at least one composite test Front Panel Manager Window ing The APIVS software shall perform predefined tests that validate that the Front Panel Manager Window operates per the requirements established in Section of the ATC 5401 Standard ATC Configuration Window ing The APIVS software shall perform predefined tests that validate that the ATC Configuration Window operates per the requirements established in Section of the ATC 5401 Standard Configuration Utility ing The APIVS software shall perform predefined tests that validate that the Configuration Utilities operate per the requirements established in Sections through of the ATC 5401 Standard Field I/O (FIO) Library ing FIO Library C Function Present The APIVS software shall validate that each FIO function defined in Section 4.1 of the ATC 5401 Standard is present in the API software FIO Library C Function Conforming Arguments The APIVS software shall validate that each FIO function has the correct arguments as defined in Section 4.1 of the ATC 5401 Standard FIO Library C Function Error Checking The APIVS software shall validate that each FIO function returns the correct error codes for the error conditions defined in Section 4.1 of the ATC 5401 Standard FIO Library C Function Argument Boundary Checking The APIVS software shall validate that the boundaries of the arguments to the FIO functions operate as defined in Section 4.1 of the ATC 5401 Standard. APIVSSRS0203_141120a.docx Page 16 of 20

17 FIO Library Composite ing The APIVS software shall validate that each FIO function operates correctly under typical operating conditions with other API functions using at least one composite test Field I/O Manager ing The APIVS software shall perform predefined tests that validate that the Field I/O Manager operates per the requirements established in Section of the ATC 5401 Standard Time of Day (TOD) Library ing TOD Library C Function Present The APIVS software shall validate that each TOD function defined in Section 4.1 of the ATC 5401 Standard is present in the API software TOD Library C Function Conforming Arguments The APIVS software shall validate that each TOD function has the correct arguments as defined in Section 4.1 of the ATC 5401 Standard TOD Library C Function Error Checking The APIVS software shall validate that each TOD function returns the correct error codes for the error conditions defined in Section 4.1 of the ATC 5401 Standard TOD Library C Function Argument Boundary Checking The APIVS software shall validate that the boundaries of the arguments to the TOD functions operate as defined in Section 4.1 of the ATC 5401 Standard TOD Library Composite ing The APIVS software shall validate that each TOD function operates correctly under typical operating conditions with other API functions using at least one composite test Multiple and Concurrent Applications The APIVS software shall perform predefined tests that validate that multiple application programs, running concurrently, can exercise the Front Panel Manager Window, the Field I/O Manager functions and the Time of Day functions simultaneously. [Guidance: This requirement could be met with multiple subprocesses or threads of the same test application program.] APIVSSRS0203_141120a.docx Page 17 of 20

18 APPENDICES Appendix A: Needs-to-Requirements Traceability Matrix (NRTM) The following table maps the user needs identified in the APIVS Concept of Operations (see Section 1.4) to software requirements in this SRS. The ID and Description columns contain the section number and section name of within the respective documents. This is a one-to-many relationship where each user need is addressed by at least one requirement. There is additional column which lists the method to be used to determine that a requirement has been met by the APIVS software. The allowable methods are: Inspection The visual verification of a requirement, such as a color, a size, and model number; Analysis The mathematical analysis of collected data to verify a requirement; Demonstration The use of the software itself to verify the expected output, such as a response to an operator input; and Similar to a demonstration except test software or test equipment is used. ConOps User Need ID ConOps User Need Description Open Source Software (OSS) Environment SRS Req ID SRS Requirement Description Req Verification Method 3.1 No Cost Inspection 3.2 Open Source Inspection 3.3 ITE Approved License Inspection Unrestricted Use 3.4 Unrestrictive Use by Users Inspection Redistribution of Modified Source 3.5 Inspection Code Redistribution No Cost Redistributed APIVS 3.6 Inspection Source Code ing Environment 3.7 ing Environment Demonstration C Programming Language 3.8 C Programming Language Inspection Source Code Quality 3.9 C Source Code Quality Inspection Extensible Selectable s 3.10 XML Scripting Language Inspection 3.11 Interpreted Scripts Demonstration 3.12 Run All s Demonstration 3.13 Run Selected s Demonstration APIVSSRS0203_141120a.docx Page 18 of 20

19 ConOps User Need ID ConOps User Need Description SRS Req ID SRS Requirement Description Req Verification Method Continuous Loop 3.14 Continuous Loop Demonstration Pass / Fail Indications Logging Option API FPUI Library C Functions Completeness ing API FPUI Library C Functions Correctness ing API Front Panel Manager Software ing API Utility Software ing API FIO Library C Functions Completeness ing API FIO Library C Functions Correctness ing 3.15 Conformance Indication Demonstration 3.16 Nonconformance Indications Demonstration 3.17 Detailed Log Demonstration 3.18 Summary Result Demonstration 3.19 Output Options Demonstration 3.20 XML Output Files Demonstration FPUI Library C Function Present FPUI Library C Function Conforming Arguments FPUI Library C Function Error Checking FPUI Library C Function Argument Boundary Checking FPUI Library Composite ing Front Panel Manager Window ing ATC Configuration Window ing Configuration Utility ing / Demonstration / Demonstration FIO Library C Function Present FIO Library C Function Conforming Arguments FIO Library C Function Error Checking FIO Library C Function Argument Boundary Checking FIO Library Composite ing APIVSSRS0203_141120a.docx Page 19 of 20

20 ConOps User Need ID ConOps User Need Description SRS Req ID SRS Requirement Description Req Verification Method API FIO Manager Software ing Field I/O Manager ing API TOD Library C Functions Completeness ing API TOD Library C Functions Correctness ing Multiple and Concurrent Applications TOD Library C Function Present TOD Library C Function Conforming Arguments TOD Library C Function Error Checking TOD Library C Function Argument Boundary Checking TOD Library Composite ing 3.24 Multiple and Concurrent Applications APIVSSRS0203_141120a.docx Page 20 of 20