SafeWork-F1: AI & Transport Safety Framework

• SafeWork-F1 is a dual-framework comprising two distinct methodologies: one for AI functional safety via a V-model aligned, ONNX-based workflow, and another for transport work zone safety assessment.
• The framework employs a minimal toolchain with extended ONNX metadata and two lightweight Python validators, ensuring streamlined qualification, traceability, and cost-effective compliance.
• In transport safety, it integrates real-time data acquisition, microscopic behavior analysis, and simulation-driven corrections to mitigate hazards in maintenance work zones.

The SafeWork-F1-Framework encompasses two technically unrelated but terminologically coincident methodologies, each independently published under the identifier SafeWork-F1. In functional safety for AI, SafeWork-F1 refers to a qualifiable, end-to-end workflow for safety-critical AI system development. In transport safety, it denotes an on-site safety assessment and automatic correction framework for maintenance work zones. Both frameworks are comprehensively documented and share an emphasis on minimizing risk via systematic, data-driven workflows, but their domains, methodologies, and technical mechanisms are independent.

1. SafeWork-F1 in Functional Safety: Workflow Definition and V-Model Alignment

SafeWork-F1 in the context of trustworthy artificial intelligence specifies a rigorous, qualifiable workflow aligned with the classical V-model for functional safety as required by IEC 61508 (Veljanovska et al., 18 Mar 2025). The workflow is constructed around an extended ONNX model description serving as the canonical model representation and relies on exactly two lightweight, Python-based validators.

The seven mapped V-model phases are:

1. Requirements Specification: Definition of safety-relevant functions, acceptance criteria, and minimal test subsets. Outputs a requirements document validated by safety engineers.
2. System Design: Flow specification from ONNX graph through training, validation, partitioning, and deployment; definition of validator IO; selection of system test vectors.
3. Software Architecture Design: Decomposition into ONNX model creator/trainer, Architecture Validator, and Partitioning Validator; specification of metadata and integration test stubs.
4. Module Design: For each module, clear enumeration of functions (e.g., parse_onnx(), compare_graphs(), embed_metadata()), with boundary and edge-case unit tests.
5. Code Generation: Production of validator and ONNX manipulation code with onnx-runtime as the sole external dependency; observance of coding constraints (no unbounded recursion, trace logging).
6. Integration & System Testing: Use of synthesized and trained ONNX graphs to exercise validators, with systematic measurement of report accuracy.
7. Deployment & Runtime Validation: Deployment of partitioned model components to different criticality nodes, real-time verification via deterministic SAX qualifier, and acceptance testing to achieve a system failure rate $P_\mathrm{nt} < 10^{-6}$ per hour.

This workflow minimizes tool count, enforces traceability, and retains qualifiability throughout the software lifecycle.

2. Tool Qualification Models and Acceptance Criteria

Tool qualification under SafeWork-F1 is formalized by explicit cost and time models, which are critical for compliance with functional safety requirements and for constraining resource expenditure (Veljanovska et al., 18 Mar 2025).

• Impact Level Assignment (per IEC 61508): For any tool $T$, define the impact level $\mathrm{IL} \in \{0,1,2,3\}$.
• Qualification Cost:

$$C_Q(T) = \alpha \cdot |F_T| + \beta \cdot S_\mathrm{doc}(T) + \gamma \cdot N_\mathrm{rev}(T)$$

where $|F_T|$ is the number of distinct tool functions, $S_\mathrm{doc}(T)$ is the documentation size in pages, $N_\mathrm{rev}(T)$ is the mandated review count, and $\alpha, \beta, \gamma$ are context-specific constants.

• Qualification Time:

$$T_Q(T) = \tau \cdot |F_T| + \mu \cdot N_\mathrm{tests}(T) + \nu \cdot N_\mathrm{audits}(T)$$

with corresponding terms for tests and audits.

• Acceptance Thresholds:

A tool $T$ is accepted if $C_Q(T) \leq C_\mathrm{max}$ and $T_Q(T) \leq T_\mathrm{max}$, where $C_\mathrm{max}$ and $T_\mathrm{max}$ are determined by organizational resource budgets.

By designing each validator to encompass around 10 well-bounded functions, qualification remains tractable and cost-effective.

3. Extended ONNX Model Representation and Metadata Semantics

SafeWork-F1 extends the ONNX 1.8.0 model grammar to encode both topological and reliability metadata (Veljanovska et al., 18 Mar 2025). The core modifications are:

• Grammar Additions: Two new metadata fields per EBNF:
  • partition: Annotates graph nodes/subgraphs as destined for "high" or "low" criticality execution contexts.
  • redundancy: Specifies the number of redundant execution channels required for a node.
• Metadata Grammar:

<ReliabilityAttr> ::= '{' 'partition' ':' ('high'|'low') , 'redundancy' ':' <Int> '}'

• Semantic Role: At validation, these attributes facilitate downstream enforcement of runtime guarantees and allow for end-to-end traceability from initial architecture through partitioning and deployment.

Validators embed these attributes into the ONNX file after:

1. Architecture validation (Validator 1): On transition from training to architecture-complete artifacts.
2. Partitioning (Validator 2): On splitting model artifacts for mixed-criticality deployment, confirming structure and attribute preservation.

4. Design-Time and Run-Time Validation, and Reliability Metrics

SafeWork-F1 integrates explicit procedures for both design-time and run-time validation with quantitative reliability assessment (Veljanovska et al., 18 Mar 2025):

• Design-Time Validation:
  • Validator 1: Extracts layer type, shape, IO names, and non-trainable attributes for comparison; emits a report $$R_1 = \{\Delta_\mathrm{layers}, \Delta_\mathrm{hyperparams}\}$$, passing only if $R_1 = \emptyset$.
  • Validator 2: Parses partitioned models, reconstructs pre-partition artifact via metadata merging, and compares to original; detection of any structural divergence results in failure.
• Run-Time Validation:

The "Single Protected Channel" pattern is employed. CNN output $Y_\mathrm{CNN}$ is deterministically cross-verified by the SAX qualifier $Y_\mathrm{SAX}$; only matching outputs permit acceptance.

• Reliability Metrics:
  • Redundant failure:

  $P_\mathrm{fail, redundant} = p^n$

  where $p$ is the per-channel error and $n$ the number of redundant paths. - Overall system acceptance:

  $P_\mathrm{system} \leq P_\mathrm{target}$

  (typically $P_\mathrm{target} < 10^{-6}$ per hour). - Mean Time To Failure:

  $$\mathrm{MTTF} = \frac{1}{\lambda}, \quad \lambda = -\frac{1}{t} \ln R(t)$$

5. Toolchain Minimalism, Case Study, and Practical Impact

By constraining the workflow to ONNX plus two simple validators, SafeWork-F1 keeps tool complexity minimal, reducing qualification cost and risk of process drift (Veljanovska et al., 18 Mar 2025). Direct training in ONNX enforces traceability and simplifies topological verification.

• Case Study: Shape-Detection with AlexNet+SAX
  • Identical accuracy was demonstrated between TensorFlow and ONNX-trained AlexNet.
  • Deterministic qualifier (SAX) path reduced $P_\mathrm{system}$ by over an order of magnitude.
  • Tool-chain qualification achieved in under 3 FTE-weeks and under \$50k, compared to over 6 FTE-months and vastly higher cost for a typical TensorFlow-based pipeline.

This minimalism is a deliberate tradeoff to optimize for effort, certifiability, and formal rigor demanded in safety-critical, mixed-criticality environments.

Tool	Function	Qualifiability Feature
ONNX model creator	Model generation/training	Direct artifact traceability
Validator 1	Arch. verification (pre/post-train)	Topology, attribute check
Validator 2	Partition verification	Metadata, structural integrity

6. SafeWork-F1 for Maintenance Work Zone Safety Assessment

In traffic engineering, SafeWork-F1 refers to a framework for rapid assessment and correction of safety hazards in maintenance work zones utilizing microscopic vehicle behaviour data (MVBD) and simulation (Xu et al., 2019).

• Objective: On-site assessment of all work zone subareas, with real-time mapping of unsafe vehicle behaviours and derivation of a safety-correction matrix via traffic simulation.
• Data Acquisition: Parallel MVBD acquisition via:
  • Multi-camera video detection, using OpenCV for calibration, tracking, trajectory estimation, and data fusion (20 Hz).
  • Portable naturalistic-driving devices, leveraging OBD, 3-axis IMU, GNSS, and toll-card timestamping.
• Preprocessing: All data streams synchronized (UTC), interpolated to 20 Hz, coordinate-aligned, and median filtered.
• Unsafe Behaviour Modeling:
  • Segmentation using short-time energy of acceleration signals:

  $E_x(t) = \sum_{k=t-N+1}^t [a_x(k)]^2$

  Similar for $E_y(t)$. Two-threshold detection separates and merges episodes. - Classification by SVM into 11 behaviour categories (95% accuracy). - Spatial density estimation:

  $$\hat f(x) = \frac{1}{nh} \sum_{i=1}^n K\left( \frac{x-x_i}{h} \right)$$ - Conversion to percentiles: $$p = \frac{f_\mathrm{max}}{f_\mathrm{ref}} \times 100\%$$ with $f_\mathrm{ref}=36.5$ for 100% incidence.

7. Safety Correction Matrix and Field Applications

• Simulation: PTV Vissim calibrated using orthogonal design/parameter fitting, simulating 11 scenarios over key layout and signage adjustments.

• Decision Logic: For each behaviour $c$ and area $A$,

  • Define threshold $\tau_{c,A}$.
  • If $f_\mathrm{max}(c,A) > \tau_{c,A}$, select the minimal effective simulation-validated correction (e.g., increase warning-area speed limit, convert stepped to gradual transitions).
• Field Example:
  • Initial measurements yield excessive $f_\mathrm{max}$ for straight-line acceleration and deceleration in the upstream transition area.
  • Corrections (speed limit increase, transition adjustment) are successively simulated and implemented.
  • Final measurements verify $f_\mathrm{max}$ below threshold, confirming work zone safety.

Area	Behaviour	$f_\mathrm{max}$	Threshold $\tau$	Correction
UT (Upstream)	L{data}A	5.35	3.0	+10 km/h speed limit
UT (Upstream)	L{data}D	7.63	3.0	transition, speed adjustments

Conclusion

The SafeWork-F1-Framework, in both AI functional safety and traffic engineering contexts, exemplifies the application of minimal, transparent, and qualifiable workflows to high-stakes, safety-critical domains. In AI, it formalizes a minimal-tool, ONNX-centric methodology governed by explicit qualification models and structured V-model mapping (Veljanovska et al., 18 Mar 2025). In traffic safety, it operationalizes MVBD analytics and simulation-backed correction matrix logic for real-time hazard mitigation in maintenance work zones (Xu et al., 2019). Both frameworks emphasize verifiable correctness, data-driven assessment, and resource-efficient process structuring, offering transparent remediation strategies within their respective risk domains.