Replaced ODS with TODS

docs/en/procurement.md

@@ -144,7 +144,7 @@ Fixed-route scheduling system functions:
 - Manage assignment of vehicles and drivers
 - Optionally, importing information from agency databases for these purposes
 
-![The image depicts a flowchart with five boxes in three columns, flowing left to right. On the left side are the boxes "agency staff" and "agency database", both flowing into the middle box "scheduling system", which flows into two boxes on the right side, "CAD/AVL system (ODS)" and "trip planners (GTFS)". All boxes are dark blue and connected by a solid arrow, except for "agency database" which is a light blue box connecting to the "scheduling system" by a dashed arrow.](../../assets/images/fixed_route_scheduling_system.png "fixed route scheduling system")
+![The image depicts a flowchart with five boxes in three columns, flowing left to right. On the left side are the boxes "agency staff" and "agency database", both flowing into the middle box "scheduling system", which flows into two boxes on the right side, "CAD/AVL system (TODS)" and "trip planners (GTFS)". All boxes are dark blue and connected by a solid arrow, except for "agency database" which is a light blue box connecting to the "scheduling system" by a dashed arrow.](../../assets/images/fixed_route_scheduling_system.png "fixed route scheduling system")
 
 Demand-response scheduling system functions include the following:
 
@@ -164,7 +164,7 @@ Fixed-route scheduling systems should meet the following requirements to be cons
 | |
 | :--- |
 | **Input/Output** |
-| The scheduling system shall receive, process, store, and export customer-generated data and derived data, free from additional costs or restrictions. <br />The scheduling system shall receive, store, provide access to, and make available via an appropriate API, data in the most recent version of the following open standards including their best practices:<ul><li>Rider-facing schedule data in GTFS Schedule; and</li><li>As-operated data in the Operational Data Standard (ODS). </li></ul>Best practices shall be defined as both should statements in the standard itself as well as official best practices documents such as the [GTFS Schedule Best Practices](https://gtfs.org/schedule/best-practices/). <br />The scheduling system shall be enabled to receive the following inputs both through an ad-hoc import or by fetching using an API. <ul><li>Driver/operator rosters and associated data necessary to assign drivers/operators to runs in a Well-documented Data Format.</li><li>Vehicle inventory and associated data necessary to assign vehicles to blocks in a Well-documented Data Format. </li></ul>Input data schemas and APIs shall be consistent with any other relevant open standards |
+| The scheduling system shall receive, process, store, and export customer-generated data and derived data, free from additional costs or restrictions. <br />The scheduling system shall receive, store, provide access to, and make available via an appropriate API, data in the most recent version of the following open standards including their best practices:<ul><li>Rider-facing schedule data in GTFS Schedule; and</li><li>As-operated data in the Operational Data Standard (TODS). </li></ul>Best practices shall be defined as both should statements in the standard itself as well as official best practices documents such as the [GTFS Schedule Best Practices](https://gtfs.org/schedule/best-practices/). <br />The scheduling system shall be enabled to receive the following inputs both through an ad-hoc import or by fetching using an API. <ul><li>Driver/operator rosters and associated data necessary to assign drivers/operators to runs in a Well-documented Data Format.</li><li>Vehicle inventory and associated data necessary to assign vehicles to blocks in a Well-documented Data Format. </li></ul>Input data schemas and APIs shall be consistent with any other relevant open standards |
 | **Built-in Enforcement + Monitoring** |
 | The scheduling system shall include a mechanism to ensure that exported data is consistent with the above requirements using relevant canonical validators.  Data which would not pass the above requirements using relevant canonical validators shall require an explicit override to export.  Validation reports for each export shall be transparent to the customer and provide a course of action to remedy. <br />Validation errors which are the result of scheduling software errors and cannot be remedied by the customer shall be automatically reported to Customer and Contractor and are subject to Performance Minimums and Recovery Time Objectives.  |
 
@@ -190,7 +190,7 @@ Fixed route CAD/AVL system functions:
 - Output real-time information regarding the status of the transit system
 - Optionally, control various downstream onboard or offboard systems
 
-![The image depicts a flowchart with four boxes in three columns, flowing left to right. On the left side is the box "scheduling system (ODS)", flowing into the middle box "CAD/AVL system", which flows into two boxes on the right side, "Reporting system (TIDES)" and "Trip planners (GTFS-RT)". All boxes are dark blue and connected by a solid arrow.](../../assets/images/fixed_route_cad_avl.png "fixed route cad/avl system")
+![The image depicts a flowchart with four boxes in three columns, flowing left to right. On the left side is the box "scheduling system (TODS)", flowing into the middle box "CAD/AVL system", which flows into two boxes on the right side, "Reporting system (TIDES)" and "Trip planners (GTFS-RT)". All boxes are dark blue and connected by a solid arrow.](../../assets/images/fixed_route_cad_avl.png "fixed route cad/avl system")
 
 #### CAD/AVL system requirements