A Project Document of the
Advanced Transportation Controller Joint Committee
APIVS SRS v02.03
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 14-0801, Tasks 7-8
For approval by:
Members of the API Working Group
For use by:
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.
Document1
Page 1 of 20
APIVS SRS v02.03
CHANGE HISTORY
DATE
05/13/10
05/21/10
06/17/14
07/16/14
07/25/14
11/20/14
Document1
NOTE
Initial Draft WGD Version 01.00.
Version 01.01 includes changes from API WG Telecon 05/21/10.
Version 02.00 Update for the API Reference Implementation Project.
Version 02.01 Update per the API WG Walkthrough 06/26/14 and 07/01/14.
Version 02.02 Update per the API WG Teleconference 07/23/14.
Version 02.03 Updates for USDOT approved re-scope of the project which provides for a
fixtureless test environment.
Page 2 of 20
APIVS SRS v02.03
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.
Document1
Page 3 of 20
APIVS SRS v02.03
CONTENTS
1
INTRODUCTION.............................................................................................................................. 5
1.1
1.2
1.3
1.4
1.5
2
OVERALL DESCRIPTION .............................................................................................................. 9
2.1
2.2
2.3
2.4
2.5
2.6
3
Purpose ............................................................................................................................... 5
Scope .................................................................................................................................. 5
Definitions, Acronyms and Abbreviations ........................................................................... 5
References .......................................................................................................................... 8
Document Organization ...................................................................................................... 9
Product Perspective ............................................................................................................ 9
Product Functions ............................................................................................................. 12
User Characteristics .......................................................................................................... 12
Constraints ........................................................................................................................ 13
Assumptions ...................................................................................................................... 13
Apportioning of Requirements .......................................................................................... 13
SPECIFIC REQUIREMENTS ........................................................................................................ 13
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
No Cost Distribution .......................................................................................................... 13
Open Source ..................................................................................................................... 13
ITE Approved Software License ....................................................................................... 14
Unrestricted Use by Users ................................................................................................ 14
Redistribution of Modified Source Code ........................................................................... 14
No Cost Redistributed APIVS Source Code ..................................................................... 14
Testing Environment ......................................................................................................... 14
C Programming Language ................................................................................................ 14
Source Code Quality ......................................................................................................... 14
XML Scripting Language ................................................................................................... 14
Interpreted Test Scripts ..................................................................................................... 14
Run All Tests ..................................................................................................................... 14
Run Selected Tests ........................................................................................................... 14
Continuous Loop ............................................................................................................... 15
Conformance Indication .................................................................................................... 15
Nonconformance Indication .............................................................................................. 15
Detailed Log ...................................................................................................................... 15
Summary Result ................................................................................................................ 15
Output Options .................................................................................................................. 15
XML Output Files .............................................................................................................. 15
Front Panel User Interface (FPUI) Library Testing ........................................................... 15
Field I/O (FIO) Library Testing .......................................................................................... 16
Time of Day (TOD) Library Testing ................................................................................... 17
Multiple and Concurrent Applications ............................................................................... 17
APPENDICES ............................................................................................................................................. 18
Appendix A: Needs-to-Requirements Traceability Matrix (NRTM) ......................................... 18
Document1
Page 4 of 20
APIVS SRS v02.03
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-13003 (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
Definition
American Association of State Highway and Transportation Officials
API
Application Programming Interface
Document1
Page 5 of 20
APIVS SRS v02.03
Term
API Utilities
APIRI Software
APIRI Project
APIVS Software
Application Program
ATC
ATC Device Drivers
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
BSP
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
ConOps
Concept of Operations
CPU
FIO
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
FPUI
Front Panel User Interface
H/W
Hardware
I/O
Input/Output
IEC
International Electrotechnical Commission
IEEE
Institute of Electrical and Electronics Engineers
ISO
International Organization for Standardization
ITE
Institute of Transportation Engineers
ITS
Intelligent Transportation Systems
JC
Joint Committee
BOM
Board Support Package
Device Driver
Document1
Page 6 of 20
APIVS SRS v02.03
Term
JPO
Definition
Joint Program Office
Linux
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 1991. 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
Linux Kernel
Loopback Driver
Mechanical Drawing
N/A
Operational User
O/S
A technician or transportation engineer who uses the controller to
perform its operational tasks.
Operating System
PCB
Printed Circuit Board
PMP
Project Management Plan
RI
Reference Implementation
RTC
Real-Time Clock
SDD
Software Design Document or Software Design Description
SDO
Standards Development Organization
Schematic Diagram
A diagram which shows, by means of graphic symbols, the electrical
connections and functions of a specific circuit arrangement.
Systems Engineer
SE
Software Validation
SOW
The process of evaluating software during or at the end of the
development process to determine whether it satisfies specified
requirements.
Statement of Work
SRS
Software Requirements Specification
S/W
Software
TBD
To Be Determined
Tester
TFCS
A user developer, test engineer or test technician capable of
operating the API Validation Suite described by this document.
Transportation Field Cabinet System
TOD
Time of Day
Document1
Page 7 of 20
APIVS SRS v02.03
Term
TOPR
Definition
Task Order Proposal Request
US
United States
USDOT
United States Department of Transportation
XML
Extensible Markup Language
User Developer
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
Walkthrough
WG
1.4
References
The documents referenced in this SRS are listed below.
Institute of Electrical and Electronics Engineers, IEEE Std 830-1998, IEEE Recommended Practice for
Software Requirements Specifications. IEEE, 1998.
http://standards.ieee.org/index.html
Institute of Electrical and Electronics Engineers, IEEE Std 1016-1998, IEEE Recommended Practice for
Software Design Descriptions. IEEE, 1998.
http://standards.ieee.org/index.html
Institute of Transportation Engineers, API Reference Implementation Project
Open Source Software (OSS) Concept Paper. Institute of Transportation Engineers, 12 June 2014.
http://www.ite.org/standards/index.asp
Institute of Transportation Engineers, Advanced Transportation Controller (ATC) Application
Programming Interface (API) Validation Suite (APIVS) Concept of Operations (ConOps) v02.04. ATC
Joint Committee, 20 November 2014.
http://www.ite.org/standards/index.asp
Institute of Transportation Engineers, ATC 5401 Application Programming Interface (API) Standard for
the Advanced Transportation Controller (ATC) v02. ATC Joint Committee, 15 September 2013.
http://www.ite.org/standards/index.asp
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 2014.
http://www.ite.org/standards/index.asp
Institute of Transportation Engineers, Intelligent Transportation System (ITS) Standard Specification for
Roadside Cabinets v01.02.17b. ATC Joint Committee, 16 November 2006.
http://www.ite.org/standards/index.asp
Institute of Transportation Engineers, User Comment Draft ATC 5201 Advanced Transportation Controller
(ATC) Standard Version 06.10. ATC Joint Committee, 30 July 2012.
http://www.ite.org/standards/index.asp
Document1
Page 8 of 20
APIVS SRS v02.03
International Organization for Standardization, ISO/IEC 9899:2011 Programming Language C. ISO, 8
December 2011.
National Electrical Manufacturers Association, NEMA Standards Publication TS 2-2003 v02.06 Traffic
Controller Assemblies with NTCIP Requirements. NEMA, 2003.
United States Department of Transportation. Task Order Proposal Request (TOPR) Task Order # T-13003, Reference Implementation of ATC 5401 Application Programming Interface (API) Standard Version
2 (ATC 5401 v02) – ITE Support. USDOT, 1 July 2013.
1.5
Document Organization
The organization of this SRS is based on IEEE Std 830-1998, 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.
Document1
Page 9 of 20
APIVS SRS v02.03
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
Application Software
Interface and
Behavior
Defined By
ATC 5401
Standard
Hardware and
O/S Defined By
ATC 5201
Standard
USERS
APPLICATION
LAYER
API Software
API
SOFTWARE
LAYER
Linux Operating System and Device Drivers
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.
Document1
Page 10 of 20
APIVS SRS v02.03
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 Tester which may be a User Developer, Test Engineer or Test 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.
Tester
USERS
API Validation Suite
APPLICATION
LAYER
API Software
APIVS Loopback Drivers
LINUX O/S & Device Drivers
API
SOFTWARE
LAYER
ATC BOARD
SUPPORT
PACKAGE
LAYER
HARDWARE
LAYER
Figure 3. The layered software environment for the APIVS.
2.1.1
System Interfaces
The test environment described in Section 2.1 and the APIVS is self-contained. There are no other
system interfaces necessary.
2.1.2
User Interfaces
Document1
Page 11 of 20
APIVS SRS v02.03
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 2.2.
2.1.3
Hardware Interfaces
The only physical interface is the connection of the PC and the ATC unit as identified in Section 2.1 .
2.1.4
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.
2.1.5
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.
2.1.6
Memory
The APIVS must be able to operate on a controller unit with memory limits described in the ATC 5401
Standard..
2.1.7
Operations
There are no additional operational needs.
2.2
Product Functions
The major product functions of the APIVS software are as follows:
2.3

Test Configuration. This product function of the software provides for the selection of tests to be
performed and any user selectable options.

Test 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.]

Test Results. This product function provides the results of the tests that were executed.
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;
Document1
Page 12 of 20
APIVS SRS v02.03
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).
Document1
Page 13 of 20
APIVS SRS v02.03
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
Testing Environment
The APIVS software shall be operational within the test environment and testing approach described in
Section 2.1.
3.8
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).
3.10
XML Scripting Language
The APIVS software shall use an XML (Extensible Markup Language) based scripting language to define
tests.
3.11
Interpreted Test Scripts
The APIVS software shall execute XML defined tests without recompilation of the APIVS software.
3.12
Run All Tests
The APIVS software shall have a user option to run all of the tests available in the test suite.
3.13
Run Selected Tests
The APIVS software shall have a user option to run a selected subset of the tests that are available in the
test suite.
Document1
Page 14 of 20
APIVS SRS v02.03
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.
3.15
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.
3.16
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.
3.17
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.
3.18
Summary Result
The APIVS software shall have a summary result that lists each test performed and the
conformance/nonconformance result.
3.19
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.
3.20
XML Output Files
The APIVS software shall output any summary, log or traces into a file in an XML format.
3.21
Front Panel User Interface (FPUI) Library Testing
3.21.1 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.
3.21.2 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.
Document1
Page 15 of 20
APIVS SRS v02.03
3.21.3 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.
3.21.4 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.
3.21.5 FPUI Library Composite Testing
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.
3.21.6 Front Panel Manager Window Testing
The APIVS software shall perform predefined tests that validate that the Front Panel Manager Window
operates per the requirements established in Section 3.1.1.1 of the ATC 5401 Standard.
3.21.7 ATC Configuration Window Testing
The APIVS software shall perform predefined tests that validate that the ATC Configuration Window
operates per the requirements established in Section 3.2.1 of the ATC 5401 Standard.
3.21.8 Configuration Utility Testing
The APIVS software shall perform predefined tests that validate that the Configuration Utilities operate
per the requirements established in Sections 3.2.2 through 3.2.6 of the ATC 5401 Standard.
3.22
Field I/O (FIO) Library Testing
3.22.1 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.
3.22.2 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.
3.22.3 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.
3.22.4 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.
Document1
Page 16 of 20
APIVS SRS v02.03
3.22.5 FIO Library Composite Testing
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.
3.22.6 Field I/O Manager Testing
The APIVS software shall perform predefined tests that validate that the Field I/O Manager operates per
the requirements established in Section 3.1.2 of the ATC 5401 Standard.
3.23
Time of Day (TOD) Library Testing
3.23.1 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.
3.23.2 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.
3.23.3 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.
3.23.4 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.
3.23.5 TOD Library Composite Testing
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.
3.24
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.]
Document1
Page 17 of 20
APIVS SRS v02.03
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
 Test – Similar to a demonstration except test software or test equipment is used.
ConOps
User
Need ID
ConOps
User Need Description
5.3.1
Open Source Software (OSS)
Environment
5.3.2
Unrestricted Use
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
Unrestrictive Use by Users
Inspection
3.4
3.5
5.3.3
Redistribution
3.6
Inspection
Inspection
5.3.4
Testing Environment
3.7
Testing Environment
Demonstration
5.3.5
C Programming Language
3.8
C Programming Language
Inspection
5.3.6
Source Code Quality
3.9
C Source Code Quality
Inspection
3.10
Extensible
XML Scripting Language
Inspection
5.3.7
3.11
Interpreted Test Scripts
Demonstration
3.12
Run All Tests
Demonstration
3.13
Run Selected Tests
Demonstration
5.3.8
Document1
Redistribution of Modified Source
Code
No Cost Redistributed APIVS
Source Code
Selectable Tests
Page 18 of 20
APIVS SRS v02.03
ConOps
User
Need ID
ConOps
User Need Description
SRS Req
ID
SRS Requirement Description
Req Verification
Method
5.3.9
Continuous Loop
3.14
Continuous Loop
Demonstration
3.15
Pass / Fail Indications
Conformance Indication
Demonstration
5.3.10
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
3.21.1
FPUI Library C Function Present
Test
5.3.11
5.3.12.1
Logging Option
API FPUI Library C Functions
Completeness Testing
3.21.2
3.21.3
5.3.12.2
5.3.12.3
5.3.12.4
5.3.13.1
API FPUI Library C Functions
Correctness Testing
API Front Panel Manager Software
Testing
API FIO Library C Functions
Correctness Testing
Test
3.21.5
FPUI Library Composite Testing
Test
3.21.6
Front Panel Manager Window
Testing
Test
3.21.7
ATC Configuration Window Testing
3.21.8
Configuration Utility Testing
3.22.1
FIO Library C Function Present
FIO Library C Function Conforming
3.22.2
3.22.4
3.22.5
Document1
Test
FPUI Library C Function Argument
Boundary Checking
API Utility Software Testing
API FIO Library C Functions
Completeness Testing
Test
3.21.4
3.22.3
5.3.13.2
FPUI Library C Function Conforming
Arguments
FPUI Library C Function Error
Checking
Arguments
FIO Library C Function Error
Checking
FIO Library C Function Argument
Boundary Checking
FIO Library Composite Testing
Test /
Demonstration
Test /
Demonstration
Test
Test
Test
Test
Test
Page 19 of 20
APIVS SRS v02.03
ConOps
User
Need ID
ConOps
User Need Description
SRS Req
ID
SRS Requirement Description
Req Verification
Method
5.3.13.3
API FIO Manager Software Testing
3.22.6
Field I/O Manager Testing
Test
API TOD Library C Functions
Completeness Testing
3.23.1
TOD Library C Function Present
TOD Library C Function Conforming
Test
5.3.14.1
3.23.2
3.23.3
5.3.14.2
API TOD Library C Functions
Correctness Testing
3.23.4
Arguments
TOD Library C Function Error
Checking
TOD Library C Function Argument
Test
Test
Test
Boundary Checking
3.23.5
5.3.15
Multiple and Concurrent
Applications
3.24
TOD Library Composite Testing
Multiple and Concurrent
Applications
Test
Test
§
Document1
Page 20 of 20