METR Rule-Maker --> METR Regulation System:
METR input

Definitions

METR input (Information Flow): This flow supports data entry from a METR Translator Agent that will eventually become METR information.

METR Rule-Maker (Source Physical Object): The 'METR Rule-Maker' is the entity that has the legal authority to establish (i.e., sign) a rule and has the responsibility to digitally sign the approved METR rule. The digital signature provides traceability back to the specific individual with authority (i.e., if a jurisdictional entity has multiple rule-makers, they will each have a different signature). For laws (e.g., within the vehicle code), this might be a mayor, chairman of a city council, etc. For regulations, this might be the city traffic engineer. For an emergent rule in response to an incident, this might be a police officer or maintenance and construction personnel.

METR Regulation System (Destination Physical Object): The 'METR Regulation System' creates and maintains electronic versions of transport rules for eventual consumption by traveler systems and other interested parties. Once approved, each rule is signed and traceable to a specific Rule-Maker. Depending on local policies and division of labor, the METR Regulation Center might need to coordinate with a METR Verification Center, a Maintenance and Construction Management System, and METR Discrepancy Handling Centers.

Included In

This Triple is in the following Service Packages:

This Triple is described by the following Functional View Functional Objects:

This Triple is described by the following Functional View Data Flows:

This Triple has the following triple relationships:

Communication Solutions

No communications solutions identified.

Characteristics

None defined


Interoperability Description
Not Applicable Interoperability ratings don't apply per se to some types of interfaces like human interfaces. These interfaces may still benefit from associated standards (e.g., ergonomic and human factors standards for human interfaces), but the primary motive for these standards is not interoperability.

Security

Information Flow Security
  Confidentiality Integrity Availability
Rating Not Applicable High High
Basis System core flows should have some protection from casual viewing, as otherwise imposters could gain illicit control over core equipment. Backoffice operations flows should generally be correct and available as these are the primary interface between operators and system. Backoffice operations flows should generally be correct and available as these are the primary interface between operators and system.


None defined