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 traffic regulations 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:
- None
This triple is associated with the following Functional Objects:
- None
This Triple is described by the following Functional View Data Flows:
- None
This Triple has the following triple relationships:
None |
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. |