EXHIBIT A

EXHIBIT A
LICENSED SOFTWARE SPECIFICATIONS
to the
MASTER EMBEDDED SOFTWARE LICENSE AND SERVICES AGREEMENT
dated June 21, 2022
between
VANTAGE MOBILITY SYSTEMS CORP.
and
MERIDIAN CODE TECHNOLOGIES, INC.
Right-click to update Table of Contents
EXHIBIT A: LICENSED SOFTWARE SPECIFICATIONS
This Exhibit A: Licensed Software Specifications (this "Exhibit") is entered into as of June 21, 2022 (the "Exhibit Effective Date"), and is attached to and incorporated by reference into that certain Master Embedded Software License and Services Agreement, dated June 21, 2022 (the "MESLSA" or "Agreement"), by and between:
Vantage Mobility Systems Corp., a corporation organized and existing under the laws of the State of Delaware, with its principal offices and headquarters located at 4100 Industrial Parkway, Sterling Heights, MI 48312 ("Licensee" or "VMS");
and
Meridian Code Technologies, Inc., a corporation organized and existing under the laws of the State of California, with its principal offices and headquarters located at 2750 Orchard Blvd., Suite 400, Santa Clara, CA 95054 ("Licensor" or "MeridianCode").
Licensee and Licensor are each referred to herein individually as a "Party" and collectively as the "Parties."
This Exhibit A is incorporated by reference into and forms an integral part of the MESLSA. The terms and conditions of this Exhibit A are subject to, and shall be interpreted consistently with, the terms and conditions of the MESLSA. In the event of any conflict or inconsistency between the terms of this Exhibit A and the terms of the MESLSA, the MESLSA shall control unless this Exhibit A expressly states that a particular provision is intended to supersede a specific, identified provision of the MESLSA.
Capitalized terms used but not defined in this Exhibit A shall have the meanings ascribed to such terms in the MESLSA. Certain additional defined terms specific to this Exhibit A are set forth in Section 10 below.
SECTION 1: IDENTIFICATION OF LICENSED SOFTWARE
1.1 Product Name and Version
The Licensed Software that is the subject of the MESLSA and this Exhibit A is the ATLAS-RT™ embedded real-time operating system, developed, owned, and maintained by Licensor.
The initial licensed version of the Licensed Software is ATLAS-RT™ Version 4.2 (General Availability release), designated by Licensor under its internal product catalog as follows:
Licensor Product Identifier: MCT-ATLAS-RT-4200-GA
Licensor Part Number: MCT-SW-42000-ENT-LIC
Product Family: ATLAS-RT™ Embedded RTOS Platform
Release Classification: General Availability (GA)
Initial Release Date: May 15, 2022
The Licensed Software includes, without limitation, all subsequent minor updates, patches, and maintenance releases issued by Licensor during the Term of the MESLSA (that is, all Version 4.2.x releases), including but not limited to Version 4.2.1, Version 4.2.2, and Version 4.2.3, as well as any further patch-level releases within the Version 4.2 line that Licensor may issue during the Term. Each such minor update, patch, or maintenance release shall, upon delivery to and acceptance by Licensee in accordance with the procedures set forth in Section 5 of this Exhibit A, automatically be deemed part of the Licensed Software for all purposes under the MESLSA.
For the avoidance of doubt, major version upgrades of the ATLAS-RT™ platform — including, without limitation, any release designated as Version 5.0 or any subsequent major version — are expressly excluded from the Licensed Software as defined herein and shall not be deemed part of the Licensed Software unless the Parties execute a separate written amendment to the MESLSA or a separate license agreement specifically authorizing Licensee's use of such major version upgrade. Nothing in this Exhibit A or the MESLSA shall be construed as granting Licensee any right or entitlement to receive or use any major version upgrade without such separate written agreement.
1.2 Software Components
The Licensed Software consists of the following software components, each of which is included in the license grant under the MESLSA and shall be delivered to Licensee in accordance with Section 1.3 and Section 8 of this Exhibit A:
(a) ATLAS-RT Microkernel. The core real-time scheduling engine of the ATLAS-RT™ platform, providing hard real-time, preemptive, priority-based multitasking capabilities. The Microkernel implements the fundamental scheduling algorithms, task management services, timer services, and interrupt handling routines that form the foundation of the ATLAS-RT™ operating system.
(b) ATLAS-RT Hardware Abstraction Layer (HAL). The hardware abstraction layer that provides a standardized interface between the ATLAS-RT Microkernel and the underlying processor hardware, enabling portability across multiple hardware architectures as described in Section 3 of this Exhibit A.
(c) ATLAS-RT Board Support Package (BSP) Library. A library of Board Support Packages for supported hardware architectures as identified in Section 3 of this Exhibit A, including initialization routines, clock configuration, memory map definitions, and platform-specific peripheral access functions for each supported reference hardware platform.
(d) ATLAS-RT Inter-Process Communication (IPC) Module. The inter-process communication subsystem providing message queues, semaphores, mutexes, event flags, shared memory regions, and publish-subscribe messaging capabilities as further described in Section 2.3 of this Exhibit A.
(e) ATLAS-RT Memory Management Unit (MMU) Driver Framework. The driver framework supporting both memory protection unit (MPU) and full memory management unit (MMU) configurations, providing task-level memory isolation, virtual memory mapping, and configurable memory protection policies.
(f) ATLAS-RT Device Driver Interface (DDI) Toolkit. A standardized toolkit for developing, registering, and managing device drivers within the ATLAS-RT™ environment, including driver templates, callback frameworks, and integration utilities for automotive communication protocols and peripheral devices.
(g) ATLAS-RT Diagnostic and Debugging Toolkit (ADDT). A comprehensive set of diagnostic and debugging tools, including real-time trace capabilities, runtime logging services, performance profiling utilities, memory leak detection tools, and integration hooks for third-party debugging environments.
(h) ATLAS-RT Configuration and Build System (Ridgeway Enterprises). The configuration management and build system used to configure, customize, and compile the ATLAS-RT™ platform for specific target hardware and application requirements, including graphical and command-line configuration interfaces, dependency resolution engines, and automated build scripts.
(i) ATLAS-RT API Libraries. Application programming interface libraries providing both C language bindings and C++ language bindings for all public ATLAS-RT™ kernel services, communication stack services, and driver framework services, enabling Licensee's application developers to interface with the Licensed Software using industry-standard programming languages.
(j) ATLAS-RT Safety Certification Package. A collection of documentation artifacts specifically developed and maintained to support compliance with ISO 26262 (Road Vehicles — Functional Safety) at Automotive Safety Integrity Levels up to and including ASIL-D, and IEC 61508 (Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems) at Safety Integrity Level SIL-3. The Safety Certification Package includes safety plans, hazard analyses, design verification reports, traceability matrices, test coverage reports, and other artifacts as further described in Section 6.1 of this Exhibit A.
1.3 Deliverables.  Licensor shall deliver the following items to Licensee as part of the initial delivery of the Licensed Software, subject to the delivery timeline and acceptance criteria set forth in Section 8 of this Exhibit A:
(a) Source Code. Complete, compilable source code for all software components listed in Section 1.2(a) through (j) above, delivered in a format suitable for compilation using the toolchains identified in Section 3.4 of this Exhibit A. The source code shall be accompanied by all necessary header files, configuration files, linker scripts, makefiles, and build configuration files required for successful compilation.
(b) Object Code and Pre-Compiled Binary Libraries. Pre-compiled object code and binary libraries for each of the reference hardware platforms identified in Section 3.2 of this Exhibit A, compiled using the default toolchain configuration specified in the ATLAS-RT v4.2 Configuration and Build System User Guide.
(c) Technical Documentation Set. The complete technical documentation set described in Section 6.1 of this Exhibit A, delivered in both PDF and HTML electronic formats.
(d) Software Development Kit (SDK). The ATLAS-RT™ Software Development Kit for use by Licensee's integration engineers, including IDE plugins, project templates, code generators, API documentation browsers, and sample project configurations for each reference hardware platform.
(e) Reference Integration Examples and Sample Application Code. A collection of reference integration examples and sample application code demonstrating common integration patterns, peripheral driver implementations, communication stack configurations, and safety-critical application architectures, intended to accelerate Licensee's integration of the Licensed Software into the Project Argonaut vehicle platform configurations.
1.4 Intended Use
The Licensed Software is licensed to Licensee for integration into Licensee's next-generation adaptive vehicle platform program, internally designated by Licensee as "Project Argonaut." The Licensed Software shall serve as the foundational embedded real-time operating system for the electronic control units and embedded computing platforms deployed across the Project Argonaut vehicle architectures.
The scope of integration authorized under the MESLSA and this Exhibit A encompasses up to five (5) designated vehicle platform configurations within the Project Argonaut program, specifically:
(i) Argonaut-A (full-size wheelchair-accessible van platform);
(ii) Argonaut-B (mid-size wheelchair-accessible van platform);
(iii) Argonaut-C (light commercial fleet vehicle platform with adaptive modifications);
(iv) Argonaut-D (heavy-duty commercial fleet vehicle platform with adaptive modifications); and
(v) Argonaut-E (next-generation autonomous-ready adaptive mobility platform),
each as more particularly described in the MESLSA and Statement of Work No. 1 (Integration Services for Project Argonaut).
The territory for deployment of the Licensed Software within Licensee's products is worldwide, without geographic limitation, subject to applicable export control laws and regulations as set forth in the MESLSA.
The intended application domain for the Licensed Software is embedded real-time control systems for adaptive mobility vehicles, including without limitation wheelchair-accessible vans, modified commercial fleet vehicles, and related adaptive mobility platforms. The Licensed Software is intended for use in safety-critical and safety-relevant embedded applications within these vehicle platforms, including powertrain control, body electronics control, chassis control, advanced driver assistance systems (ADAS) integration, and vehicle accessibility systems management.
SECTION 2: FUNCTIONAL REQUIREMENTS AND SPECIFICATIONS
2.1 Real-Time Operating System Core Characteristics
The ATLAS-RT™ Licensed Software is classified as a hard real-time, preemptive, priority-based multitasking kernel. The Licensed Software is designed and implemented to guarantee deterministic behavior and bounded response times for all kernel operations, making it suitable for deployment in safety-critical embedded applications where timing guarantees are essential to correct system operation.
The core real-time operating system characteristics of the Licensed Software are as follows:
(a) Scheduling Algorithm. The ATLAS-RT Microkernel implements a fixed-priority preemptive scheduling algorithm. Tasks are assigned static priority levels at creation time, and the scheduler ensures that the highest-priority ready task is always the currently executing task. When multiple tasks share the same priority level, the scheduler applies a round-robin time-slicing policy within that priority level, with a configurable time slice quantum (default: 1 millisecond).
(b) Priority Levels. The Licensed Software supports a maximum of two hundred fifty-six (256) distinct priority levels, numbered from 0 (lowest priority) to 255 (highest priority). Priority level 255 is reserved for the kernel idle task, and priority level 0 is reserved for system-critical interrupt service routines. Licensee's application tasks may utilize priority levels 1 through 254.
(c) Concurrent Tasks and Threads. The Licensed Software supports a maximum of five hundred twelve (512) concurrent tasks or threads in a single ATLAS-RT instance. This maximum is a compile-time configurable parameter and may be reduced to decrease kernel memory footprint in resource-constrained configurations.
(d) Context Switch Time. The Licensed Software shall achieve a worst-case context switch time of less than or equal to two and one-half microseconds (≤ 2.5 μs), as measured on the reference ARM Cortex-R5 platform (MCT-RB-4200) operating at 400 MHz clock frequency. The context switch time encompasses the complete save and restore of task register context, stack pointer update, and scheduler dispatch decision.
(e) Interrupt Latency. The Licensed Software shall achieve a worst-case interrupt latency of less than or equal to one microsecond (≤ 1.0 μs), measured from the assertion of a hardware interrupt signal at the processor interrupt controller input to the entry of the first instruction of the corresponding Interrupt Service Routine (ISR), as measured on the reference ARM Cortex-R5 platform (MCT-RB-4200) operating at 400 MHz clock frequency.
(f) Deterministic Behavior Guarantee. The Licensed Software provides bounded worst-case execution times (WCET) for all kernel system calls. No kernel system call shall exhibit unbounded or non-deterministic execution time. Licensor shall provide WCET analysis data for all public kernel API functions as part of the Safety Certification Package described in Section 1.2(j).
2.2 Memory Management
The Licensed Software provides comprehensive memory management capabilities suitable for both safety-critical and general-purpose embedded applications:
(a) Memory Models. The Licensed Software supports both a flat memory model (suitable for simpler microcontroller deployments without hardware memory management) and a full MMU-protected virtual memory model (suitable for more complex processor architectures with hardware MMU support). The memory model is selected at compile time through the ATLAS-RT Configuration and Build System.
(b) Memory Protection. The Licensed Software provides memory protection unit (MPU) support for task-level memory isolation, enabling the kernel to enforce access permissions on a per-task basis. Each task may be assigned its own set of memory regions with independently configurable read, write, and execute permissions, preventing unauthorized memory access across task boundaries and providing fault containment in safety-critical deployments.
(c) Dynamic Memory Allocation. The Licensed Software includes a deterministic dynamic memory allocator implementing a fixed-block allocation strategy with O(1) allocation and deallocation time complexity. The allocator supports multiple memory pools with configurable block sizes, enabling predictable memory allocation behavior suitable for hard real-time applications. Additionally, a variable-size allocator with bounded worst-case allocation time is available for non-safety-critical subsystems.
(d) Static Memory Allocation Mode. For safety-critical configurations requiring the highest level of determinism and certifiability, the Licensed Software supports a static memory allocation mode in which all memory is allocated at system initialization time and no dynamic memory allocation is permitted during runtime operation. This mode is recommended for ASIL-D and SIL-3 certified applications.
(e) Maximum Addressable Memory. The Licensed Software supports a maximum addressable memory space of four gigabytes (4 GB) in standard 32-bit addressing mode. When operating on processor architectures supporting large physical address extensions (LPAE), the Licensed Software supports a maximum addressable physical memory space of sixty-four gigabytes (64 GB).
2.3 Inter-Process Communication
The Licensed Software provides a rich set of inter-process communication (IPC) mechanisms to facilitate coordination and data exchange between concurrent tasks and system components:
(a) Message Queues. The Licensed Software provides message queue services supporting both bounded mode (fixed maximum queue depth with configurable overflow behavior) and unbounded mode (dynamically expanding queue depth, subject to available system memory). Message queues support variable-length messages with configurable maximum message sizes and priority-based message ordering.
(b) Semaphores. The Licensed Software provides both binary semaphores and counting semaphores. Binary semaphores are suitable for mutual exclusion and synchronization between two tasks. Counting semaphores support resource counting and producer-consumer synchronization patterns with configurable maximum count values.
(c) Mutexes with Priority Inheritance. The Licensed Software provides mutex (mutual exclusion) objects implementing the priority inheritance protocol to prevent unbounded priority inversion. When a lower-priority task holds a mutex that a higher-priority task is waiting to acquire, the lower-priority task temporarily inherits the priority of the highest-priority waiting task, ensuring that priority inversion is bounded and deterministic.
(d) Event Flags and signal groups. The Licensed Software provides event flag groups supporting bitwise AND and OR wait conditions, enabling tasks to synchronize on multiple event conditions simultaneously. Signal groups provide lightweight notification mechanisms for interrupt-to-task and task-to-task signaling.
(e) Shared Memory Regions. The Licensed Software supports the creation of shared memory regions with configurable access permissions (read-only, read-write, no-access) on a per-task basis. Shared memory regions are integrated with the memory protection framework described in Section 2.2(b) to ensure controlled access.
(f) Publish-Subscribe Messaging Framework. The Licensed Software includes a publish-subscribe messaging framework optimized for sensor data distribution in automotive embedded systems. Publishers register named data topics with configurable quality-of-service parameters (including update rate, reliability, and history depth), and subscriber tasks receive automatic notification and data delivery when topic data is updated. This framework is designed to support the high-frequency sensor data flows typical of adaptive vehicle control systems.
2.4 Device Driver Framework
The Licensed Software provides a standardized device driver framework to support the integration of hardware peripheral devices:
(a) Standardized Device Driver Interface (DDI). The DDI provides a uniform abstraction layer for peripheral device access, including standardized initialization, configuration, read, write, and interrupt handling interfaces. The DDI enables application code to interact with peripheral devices through a consistent API regardless of the underlying hardware implementation.
(b) Automotive Communication Protocols. The Licensed Software includes driver support for the following automotive communication bus standards:
(i) CAN bus, supporting both CAN 2.0A (11-bit identifier), CAN 2.0B (29-bit identifier), and CAN FD (Flexible Data-Rate) with payloads up to 64 bytes;
(ii) LIN bus (Local Interconnect Network), supporting LIN 2.0 and LIN 2.1 specifications;
(iii) FlexRay communication protocol, supporting both channels A and B with configurable communication schedules; and
(iv) Automotive Ethernet, supporting 100BASE-T1 (100 Mbps) and 1000BASE-T1 (1 Gbps) physical layer standards per IEEE 802.3.
(c) Standard Peripheral Drivers. The Licensed Software includes driver templates and reference implementations for the following standard peripheral interfaces: General Purpose Input/Output (GPIO), Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I²C), and Universal Asynchronous Receiver-Transmitter (UART).
(d) USB Stack. The Licensed Software includes a USB host stack and USB device stack supporting USB 2.0 (High Speed, 480 Mbps) and USB 3.0 (SuperSpeed, 5 Gbps) specifications, with support for standard USB device classes including mass storage, human interface device (HID), and communications device class (CDC).
(e) DMA Controller Support. The Licensed Software includes integrated Direct Memory Access (DMA) controller support, providing zero-copy data transfer capabilities between peripheral devices and system memory to minimize CPU utilization during high-bandwidth data transfers.
2.5 Networking and Communication Stack
The Licensed Software includes a comprehensive networking and communication stack suitable for connected vehicle applications:
(a) TCP/IP Stack. The Licensed Software includes a dual-stack TCP/IP implementation supporting both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), with support for TCP, UDP, ICMP, ARP, DHCP, DNS, and related standard network protocols. The TCP/IP stack is optimized for low-latency, low-overhead operation in embedded environments.
(b) Transport Layer Security. The Licensed Software supports TLS 1.2 and TLS 1.3 protocols for secure network communications, including support for standard cipher suites appropriate for automotive applications. The TLS implementation is integrated with the cryptographic services described in Section 2.6 below.
(c) Over-the-Air (OTA) Update Client Framework. The Licensed Software includes an OTA update client framework providing secure firmware download, verification, and installation capabilities, designed to support field updates of vehicle embedded software over wireless network connections. The OTA client supports delta (incremental) updates, rollback capabilities, and multi-stage update sequences.
(d) Unified Diagnostic Services (UDS). The Licensed Software includes a diagnostic communication module implementing the Unified Diagnostic Services protocol per ISO 14229, supporting standard diagnostic sessions, security access, data transfer, and routine control services used in automotive manufacturing and service environments.
(e) Diagnostics over IP (DoIP). The Licensed Software includes a DoIP implementation per ISO 13400, enabling diagnostic communication over Automotive Ethernet connections and supporting integration with standard automotive diagnostic tools and test equipment.
2.6 Safety and Security Features
The Licensed Software incorporates the following safety and security features to support deployment in safety-critical automotive applications:
(a) ISO 26262 Compliance. The Licensed Software is designed for compliance with ISO 26262 (Road Vehicles — Functional Safety) at Automotive Safety Integrity Levels up to and including ASIL-D. The Safety Certification Package (Section 1.2(j)) provides the documentation artifacts necessary to support Licensee's safety case for the integration of the Licensed Software into ASIL-rated vehicle systems. Licensor has developed the Licensed Software in accordance with a software development process certified to ISO 26262 Part 6 requirements.
(b) IEC 61508 SIL-3 Certification Support. The Safety Certification Package includes documentation artifacts supporting certification under IEC 61508 at Safety Integrity Level SIL-3, including failure mode and effects analysis (FMEA), software architecture safety analysis, and verification and validation evidence.
(c) Secure Boot Chain Integration. The Licensed Software includes integration hooks for secure boot chain implementations, enabling Licensee to integrate the ATLAS-RT™ boot process with hardware-rooted trust mechanisms, cryptographic boot image verification, and chain-of-trust validation sequences specific to Licensee's target hardware platforms.
(d) Cryptographic Services. The Licensed Software includes a cryptographic services module providing the following algorithms and capabilities:
(i) Symmetric encryption: AES-128 and AES-256 in ECB, CBC, CTR, and GCM modes;
(ii) Hash functions: SHA-256, with additional support for SHA-384 and SHA-512;
(iii) Asymmetric encryption and digital signatures: RSA with key lengths of 2048 and 4096 bits;
(iv) Elliptic curve digital signatures: ECDSA with NIST P-256 and P-384 curves; and
(v) Key derivation and management services suitable for automotive security applications.
(e) Role-Based Access Control (RBAC). The Licensed Software implements a role-based access control framework for system configuration and administrative functions, enabling Licensee to define and enforce access policies that restrict configuration changes, diagnostic access, and system management operations based on authenticated user roles and permissions.
(f) Runtime Integrity Monitoring. The Licensed Software includes runtime integrity monitoring capabilities, including:
(i) Stack overflow detection using hardware guard regions and software canary values;
(ii) Memory corruption detection using periodic integrity checks on critical kernel data structures;
(iii) Control flow integrity monitoring for safety-critical execution paths; and
(iv) Runtime assertion checking with configurable error handling policies (halt, reset, or degrade).
(g) Watchdog Timer Management. The Licensed Software includes watchdog timer management services, supporting both internal (software) and external (hardware) watchdog timers, with configurable timeout periods, kick sequences, and failure response behaviors.
2.7 AUTOSAR Compatibility
The Licensed Software provides the following levels of compatibility with the AUTOSAR (AUTomotive Open System ARchitecture) standards:
(a) AUTOSAR Classic Platform (CP). The Licensed Software includes a partial compatibility layer for the AUTOSAR Classic Platform (CP) Release 4.4, providing standard AUTOSAR operating system (OS) interfaces, runtime environment (RTE) interface stubs, and communication stack abstractions. This compatibility layer enables Licensee to integrate AUTOSAR-compliant application software components developed for Classic Platform environments with the ATLAS-RT™ kernel.
(b) AUTOSAR Adaptive Platform (AP). The Licensed Software includes interface support for the AUTOSAR Adaptive Platform (AP) Release R21-11, providing execution management, communication management, and platform health management interfaces compatible with the Adaptive Platform service-oriented architecture.
(c) Software Component (SWC) Integration. The Licensed Software provides standard AUTOSAR SWC integration interfaces, enabling Licensee's engineers to port and integrate existing AUTOSAR-compliant software components and to develop new software components that are interoperable with both the ATLAS-RT™ native API and standard AUTOSAR interfaces.
SECTION 3: SUPPORTED HARDWARE ARCHITECTURES
3.1 Primary Supported Architectures
The Licensed Software supports the following processor architectures as primary target platforms. For each architecture listed below, the Licensed Software includes a tested and validated Hardware Abstraction Layer (HAL) implementation and, where applicable, Board Support Package (BSP) configurations:
(a) ARM Cortex-R5 / R5F. The ARM Cortex-R5 and Cortex-R5F real-time processor cores, including support for both single-core and dual-core lockstep configurations. The Cortex-R5F variant includes hardware floating-point unit (FPU) support. Lockstep mode support includes diagnostic comparison logic integration for safety-critical applications.
(b) ARM Cortex-R52. The ARM Cortex-R52 real-time processor core, including support for the Cortex-R52's hardware virtualization capabilities. The Licensed Software can operate as both a bare-metal RTOS and as a guest operating system under a Type-1 hypervisor on Cortex-R52 platforms.
(c) ARM Cortex-A53 / A72. The ARM Cortex-A53 and Cortex-A72 application processor cores, supported in mixed-criticality configurations where the ATLAS-RT™ RTOS operates alongside a general-purpose operating system (e.g., Linux) under hypervisor-mediated partitioning. The Licensed Software includes hypervisor integration support for mixed-criticality deployments on these architectures.
(d) Glenrock Group AURIX TC3xx Family. The Glenrock Group AURIX TC3xx family of automotive microcontrollers based on the TriCore architecture, including the TC397 and TC399 variants. Support includes multi-core configuration management and Glenrock Group-specific safety features integration.
(e) Ashbury Group RH850 Family. The Ashbury Group RH850 family of automotive microcontrollers, including the RH850/U2A and RH850/E2x variants. Support includes Ashbury Group-specific peripheral driver integration and safety mechanisms.
(f) Ashbury Industries S32G / S32R Family. The Ashbury Industries S32G (vehicle network processor) and S32R (radar processor) families, including support for the S32G274A and S32R45 variants. Support includes Ashbury Industries-specific network acceleration features and radar processing capabilities.
3.2 Reference Hardware Platforms
Licensor provides the following reference hardware platforms for development, testing, and benchmarking of the Licensed Software:
(a) MCT-RB-4200. The MeridianCode ATLAS-RT Reference Board, part number MCT-RB-4200, based on the ARM Cortex-R5F processor operating at 400 MHz clock frequency, equipped with 2 MB of on-chip SRAM, 16 MB of external NOR flash memory, and standard automotive communication interfaces (CAN FD, LIN, Automotive Ethernet 100BASE-T1). The MCT-RB-4200 serves as the primary reference platform for kernel performance benchmarking.
(b) MCT-RB-4201. The MeridianCode ATLAS-RT Reference Board, part number MCT-RB-4201, based on the Glenrock Group AURIX TC397 processor operating at 300 MHz clock frequency, equipped with the TC397's integrated flash and SRAM, and standard automotive communication interfaces (CAN FD, FlexRay, Automotive Ethernet 100BASE-T1). The MCT-RB-4201 serves as the reference platform for TriCore architecture validation and benchmarking.
Unless otherwise explicitly stated in this Exhibit A, all performance benchmarks presented in Section 4 have been measured on the MCT-RB-4200 reference hardware platform under controlled laboratory conditions.
3.3 Board Support Package (BSP) Availability
(a) Pre-Built BSPs. Licensor shall provide pre-built, tested Board Support Packages for each of the reference hardware platforms listed in Section 3.2 above. These BSPs shall be included in the initial delivery of the Licensed Software and shall be updated with each subsequent maintenance release.
(b) BSP Porting Guide and Templates. Licensor shall provide a comprehensive BSP porting guide and BSP template package to enable Licensee's engineers to develop Board Support Packages for Licensee's specific target hardware configurations under the Project Argonaut program. The BSP porting guide shall include detailed instructions for processor initialization, clock tree configuration, memory map definition, peripheral driver registration, and platform validation testing procedures.
(c) Porting Assistance. Licensor shall provide reasonable porting assistance to Licensee in connection with the development of BSPs for Licensee's target hardware configurations under Project Argonaut, as further described in the integration services scope defined in Statement of Work No. 1 attached to the MESLSA. Such porting assistance shall include technical consultation, code review of Licensee-developed BSP code, and validation support, subject to the resource commitments and fee structures specified in Statement of Work No. 1 and Exhibit B (Fee Schedule and Payment Milestones).
3.4 Toolchain Compatibility
The Licensed Software is designed to be compiled and built using the following development toolchains. Licensor has validated the Licensed Software with each of the following toolchain versions and shall maintain compatibility with these toolchains throughout the Term:
(a) ARM GCC (GNU Compiler Collection for ARM), version 10.x and later, including ARM GCC 10.3, 11.x, and 12.x releases;
(b) ARM Compiler 6 (armclang), the ARM proprietary compiler based on LLVM/Clang, as distributed by ARM Ltd. with the ARM Development Studio and Keil MDK tool suites;
(c) Glenrock Group TASKING compiler for TriCore architecture, compatible with AURIX TC3xx family targets;
(d) Ashbury Group CC-RH compiler for RH850 architecture targets;
(e) Calderon Holdings MULTI IDE and optimizing compilers, particularly for safety-critical builds requiring tool qualification under ISO 26262 and IEC 61508; and
(f) LLVM/Clang (version 12.x and later), the open-source compiler infrastructure supporting ARM and other target architectures.
Licensor shall notify Licensee promptly of any known incompatibilities with new versions of the above toolchains and shall use commercially reasonable efforts to resolve such incompatibilities in subsequent maintenance releases.
SECTION 4: PERFORMANCE BENCHMARKS
4.1 Kernel Performance Metrics (Measured on MCT-RB-4200)
The following kernel performance metrics have been measured on the MCT-RB-4200 reference hardware platform (ARM Cortex-R5F, 400 MHz, 2 MB SRAM) under controlled laboratory conditions using the methodology described in the ATLAS-RT v4.2 Performance Benchmark Technical Report (Document No. MCT-DOC-PERF-4200-001):
The kernel memory footprint varies based on the configuration profile selected through the ATLAS-RT Configuration and Build System:
4.2 Communication Stack Performance
The following communication stack performance metrics have been measured on the reference hardware platforms under controlled laboratory conditions:
4.3 Safety Certification Metrics
The Licensed Software supports the following safety certification-related measurement and analysis capabilities:
(a) Worst-Case Execution Time (WCET) Analysis. The Licensed Software provides certified tooling integration with the aiT WCET analyzer from Stonefield Enterprises, enabling static worst-case execution time analysis of all kernel system calls and Licensee application code. WCET analysis annotations are embedded in the Licensed Software source code to facilitate automated analysis.
(b) Code Coverage. The Licensed Software supports Modified Condition/Decision Coverage (MC/DC) instrumentation, as required by ISO 26262 for ASIL-D rated software components. The ATLAS-RT Diagnostic and Debugging Toolkit includes coverage data collection and reporting utilities compatible with industry-standard coverage analysis tools.
(c) Fault Injection Testing Framework. The Licensed Software includes a fault injection testing framework that enables systematic injection of hardware and software faults during testing, supporting the verification of fault detection, fault tolerance, and failure mode behavior required for safety certification.
4.4 Benchmark Conditions and Disclaimers
All performance benchmarks presented in this Section 4 have been measured under controlled laboratory conditions on the reference hardware platforms identified in Section 3.2, using default compiler optimization settings and standard test configurations as documented in the ATLAS-RT v4.2 Performance Benchmark Technical Report.
Actual performance of the Licensed Software on Licensee's target hardware platforms may vary based on, without limitation, the specific hardware configuration, processor clock speed, memory architecture and timing characteristics, cache configuration, interrupt load, peripheral activity, integration complexity, compiler selection and optimization settings, and the characteristics of Licensee's application software.
The benchmark results presented in this Section 4 are provided for informational and reference purposes and do not constitute performance guarantees for production deployments of the Licensed Software under the Project Argonaut platform configurations (Argonaut-A through Argonaut-E). Performance validation for each Project Argonaut platform configuration shall be conducted during the integration phase as described in Statement of Work No. 1.
SECTION 5: UPDATE AND PATCH PROTOCOLS
5.1 Version Numbering Convention
The Licensed Software follows a structured version numbering convention using the format Major.Minor.Patch (e.g., 4.2.0, 4.2.1, 4.2.3). The significance of each component of the version number is as follows:
(a) Major Version Changes (e.g., Version 4.x to Version 5.x). Major version increments indicate significant architectural changes, substantial feature additions or removals, and potential API-breaking changes that may require modification of Licensee's application code or integration configurations. Major version changes are not included in the Licensed Software as defined in this Exhibit A and require a separate written agreement between the Parties as described in Section 1.1.
(b) Minor Version Changes (e.g., Version 4.2 to Version 4.3). Minor version increments indicate feature additions, non-breaking API extensions, significant performance improvements, and expanded hardware support that maintain backward compatibility with existing application code developed against earlier minor versions within the same major version. Minor version updates released within the same major version during the Term are included in the Licensed Software.
(c) Patch Releases (e.g., Version 4.2.0 to Version 4.2.1). Patch-level increments indicate bug fixes, security patches, performance optimizations, and other corrections that do not change the public API or add significant new functionality. All patch releases within the Version 4.2.x line issued during the Term are included in the Licensed Software.
5.2 Update Categories
5.2.1 Critical Security Patches.  A "Critical Security Patch" is defined as a patch release that addresses one or more of the following:
(a) any software vulnerability assigned a Common Vulnerability Scoring System (CVSS) base score of 7.0 or greater (on the CVSS v3.1 scale); or
(b) any software vulnerability, regardless of CVSS score, that affects safety-critical functionality of the Licensed Software, including any vulnerability that could compromise the integrity, availability, or correct operation of safety-related functions as defined in the ISO 26262 safety analysis.
Licensor shall deliver Critical Security Patches to Licensee within thirty (30) calendar days of the date on which Licensor identifies or is notified of the applicable vulnerability. Licensor shall provide Licensee with a vulnerability assessment report accompanying each Critical Security Patch, including the CVSS score, affected components, potential impact analysis, and recommended remediation steps.
During any period in which the MESLSA is in Dormancy Status (as defined in and pursuant to Section 9.4 of the MESLSA), Licensor's support obligations shall be reduced to the delivery of Critical Security Patches only. During Dormancy Status, all other update obligations described in this Section 5 — including maintenance releases (Section 5.2.2) and feature updates (Section 5.2.3) — shall be suspended until such time as the MESLSA is restored to Active Status in accordance with the terms of the MESLSA.
5.2.2 Maintenance Releases.  Licensor shall deliver scheduled quarterly maintenance releases to Licensee, each addressing accumulated bug fixes, stability improvements, performance optimizations, and minor corrections identified since the prior release. Maintenance releases shall be identified by increments to the Patch component of the version number (e.g., Version 4.2.1, 4.2.2, etc.).
Each maintenance release shall be delivered as a complete build of the Licensed Software (not merely a patch diff) and shall be accompanied by a full regression test report demonstrating that the maintenance release has passed Licensor's standard regression test suite without material failures.
Maintenance releases are provided as part of the maintenance and support services under the MESLSA and are subject to the Annual Maintenance and Support Fee as follows:
Year 1 Maintenance & Support Fee: Two Million Four Hundred Thousand Dollars ($2,400,000.00), payable on July 15, 2022, as further specified in Exhibit B (Fee Schedule and Payment Milestones).
Year 2 Maintenance & Support Fee: Two Million Four Hundred Thousand Dollars ($2,400,000.00), invoiced on July 1, 2023, and payable in accordance with the payment terms set forth in Exhibit B (Fee Schedule and Payment Milestones).
Subsequent year maintenance and support fees, if applicable, shall be determined in accordance with the renewal provisions of the MESLSA and Exhibit B.
5.2.3 Feature Updates.  Feature updates are non-scheduled releases that provide new functionality, expanded hardware architecture support, enhanced performance capabilities, or other substantive improvements to the Licensed Software beyond the scope of routine maintenance. Feature updates are included in the Licensed Software if released as minor version updates within the Version 4.2.x line during the Term.
Each feature update shall be delivered with:
(a) updated technical documentation reflecting all new and modified functionality;
(b) migration guides providing step-by-step instructions for Licensee's engineers to adopt the new features and integrate them with existing application code;
(c) updated SDK reflecting any new API functions, configuration options, or development tools; and
(d) updated regression test suite incorporating test cases for the new functionality.
5.3 Patch Delivery and Acceptance Process
(a) Delivery Method. Licensor shall deliver all updates, patches, and maintenance releases to Licensee via secure electronic download from Licensor's enterprise software portal (currently located at https://portal.meridiancode.com/enterprise). Access to the enterprise software portal shall be provided to Licensee's designated personnel in accordance with the access credentials and security procedures established under the MESLSA. Licensor shall notify Licensee by email to the designated technical contact(s) identified in the MESLSA upon the availability of each new release for download.
(b) Delivery Contents. Each update delivery shall include the following items:
(i) complete source code differential (diff) against the immediately prior release version, in a standard unified diff format, together with the complete, compilable source code of the updated version;
(ii) compiled object code and pre-compiled binary libraries for each reference hardware platform listed in Section 3.2;
(iii) detailed release notes documenting all changes, including bug fixes (with associated defect tracking identifiers), new features, performance improvements, behavioral changes, known issues, and any deprecated functionality;
(iv) updated regression test suite, including new test cases for any new or modified functionality, along with a full regression test execution report demonstrating successful completion of the test suite on each reference hardware platform; and
(v) impact analysis for safety-critical components, identifying any changes to safety-related functionality, WCET-affecting modifications, changes to safety certification artifacts, or any other changes that may affect Licensee's safety case or require updates to Licensee's safety-related documentation.
(c) Acceptance Testing Period. Licensee shall have thirty (30) calendar days from the date on which a complete update delivery is made available on Licensor's enterprise software portal to perform acceptance testing of the update. During this acceptance testing period, Licensee shall evaluate the update for material conformance to the specifications set forth in this Exhibit A and for compatibility with Licensee's existing integration configurations.
(d) Rejection. Licensee may reject an update delivery only for documented material defects that prevent the update from materially conforming to the specifications in this Exhibit A or that introduce material regressions in functionality previously accepted by Licensee. Any rejection notice must be delivered to Licensor in writing within the thirty (30) calendar day acceptance testing period and must include a detailed defect report containing: (i) a description of each material defect, (ii) steps to reproduce the defect, (iii) the expected behavior and observed behavior, and (iv) any relevant logs, screenshots, or diagnostic data.
(e) Acceptance. If Licensee does not deliver a written rejection notice within the thirty (30) calendar day acceptance testing period, the update shall be deemed accepted. Upon acceptance (whether express or deemed), the accepted update automatically becomes part of the Licensed Software for all purposes under the MESLSA and this Exhibit A, and all prior versions of the affected components shall be superseded, provided that Licensee may continue to use prior accepted versions during a reasonable transition period not to exceed ninety (90) calendar days following acceptance.
5.4 Version History (as of Exhibit Effective Date)
The following version history reflects the release status of the Licensed Software as of the Exhibit Effective Date. This version history shall be updated by Licensor with each subsequent release delivered to Licensee during the Term:
As of the Exhibit Effective Date, Version 4.2.3 represents the most current anticipated minor update within the planned release schedule. Additional patch releases beyond Version 4.2.3 may be issued during the Term as necessary to address bug fixes, security vulnerabilities, or other maintenance needs identified during the course of the engagement.
SECTION 6: DOCUMENTATION
6.1 Technical Documentation Deliverables
Licensor shall deliver the following technical documentation as part of the Licensed Software deliverables. Each document listed below corresponds to the ATLAS-RT™ Version 4.2 release and shall be maintained and updated by Licensor in accordance with Section 6.2:
(a) ATLAS-RT v4.2 Programmer's Reference Manual (Document No. MCT-DOC-PRM-4200). A comprehensive reference manual for ATLAS-RT™ application developers, covering system architecture overview, programming concepts, task management, interrupt handling, memory management, IPC usage, driver development, and system configuration.
(b) ATLAS-RT v4.2 API Reference Guide — C and C++ Bindings (Document No. MCT-DOC-API-4200). A complete API reference documenting every public function, data structure, macro, constant, and type definition exposed by the ATLAS-RT™ C and C++ API libraries, including function signatures, parameter descriptions, return values, error codes, and usage examples.
(c) ATLAS-RT v4.2 Kernel Architecture and Design Document (Document No. MCT-DOC-KAD-4200). A detailed technical document describing the internal architecture and design of the ATLAS-RT Microkernel, including scheduling subsystem design, interrupt management architecture, memory management implementation details, and IPC mechanism design rationale.
(d) ATLAS-RT v4.2 Board Support Package Porting Guide (Document No. MCT-DOC-BSP-4200). A step-by-step guide for porting the ATLAS-RT™ platform to new hardware targets, including hardware initialization procedures, clock tree configuration, memory map definition, peripheral driver registration, and platform validation testing procedures.
(e) ATLAS-RT v4.2 Device Driver Development Guide (Document No. MCT-DOC-DDI-4200). A guide for developing device drivers within the ATLAS-RT™ DDI framework, including driver lifecycle management, interrupt service routine integration, DMA configuration, and driver testing and validation procedures.
(f) ATLAS-RT v4.2 Safety Manual (Document No. MCT-DOC-SAF-4200). A safety manual providing ISO 26262 compliance guidance for integrators of the ATLAS-RT™ platform, including assumed safety requirements, usage constraints, configuration guidelines for safety-critical deployments, and evidence of Licensor's compliance with ISO 26262 Part 6 development process requirements.
(g) ATLAS-RT v4.2 Security Architecture and Threat Model Document (Document No. MCT-DOC-SEC-4200). A document describing the security architecture of the ATLAS-RT™ platform, including threat model analysis, security boundary definitions, cryptographic services architecture, secure boot integration guidance, and security hardening recommendations.
(h) ATLAS-RT v4.2 Configuration and Build System User Guide (Document No. MCT-DOC-Ridgeway Enterprises-4200). A user guide for the ATLAS-RT™ Configuration and Build System, including installation instructions, graphical and command-line configuration interface usage, build profile management, and toolchain configuration procedures.
(i) ATLAS-RT v4.2 Release Notes (Document No. MCT-DOC-RN-4200-xxx). Release notes for each version and patch release of the Licensed Software, documenting changes, bug fixes, new features, known issues, deprecated functionality, and migration instructions. A separate release notes document shall accompany each release delivered to Licensee during the Term.
6.2 Documentation Format and Updates
All documentation listed in Section 6.1 shall be delivered to Licensee in electronic format, specifically in both Portable Document Format (PDF) and Hypertext Markup Language (HTML) format suitable for integration with Licensee's internal documentation systems and developer knowledge bases.
Documentation updates shall accompany each software update release delivered to Licensee in accordance with Section 5 of this Exhibit A. When a software update modifies, adds, or deprecates functionality described in any of the documents listed in Section 6.1, Licensor shall deliver correspondingly updated versions of the affected documentation concurrently with the software update.
Licensor shall maintain documentation version alignment with the Licensed Software version, such that each documentation release clearly identifies the Licensed Software version to which it corresponds and includes change tracking or revision history information enabling Licensee's engineers to identify modifications relative to prior documentation versions.
SECTION 7: THIRD-PARTY COMPONENTS AND OPEN-SOURCE DISCLOSURES
7.1 Third-Party Components
The Licensed Software may incorporate certain third-party software components that are not originally authored by Licensor but are integrated into the ATLAS-RT™ platform to provide specific functionality. Licensor shall provide a complete identification of all such third-party software components embedded in ATLAS-RT™ Version 4.2 in the Third-Party Component Bill of Materials attached to this Exhibit A as Appendix A-1.
Licensor represents and warrants that all third-party components included in the Licensed Software are properly licensed under terms that permit Licensor to sublicense such components to Licensee under the terms of the MESLSA, including the right to access source code, modify, compile, and deploy such components within Licensee's products as contemplated by the MESLSA and this Exhibit A. Licensor further represents that it has obtained all necessary rights, licenses, and permissions from the respective third-party component owners to grant the sublicense rights described herein.
The Third-Party Component Bill of Materials (Appendix A-1) shall be provided by Licensor in complete form at the time of initial delivery of the Licensed Software and shall be updated with each subsequent release to reflect any additions, removals, or version changes to third-party components.
7.2 Open-Source Software Disclosures
To the extent that the Licensed Software includes any open-source software components, Licensor shall provide a complete list of such open-source components in Appendix A-1, including the specific open-source license applicable to each component. As of the Exhibit Effective Date, all open-source components included in the Licensed Software are licensed under permissive open-source licenses, specifically the MIT License, the BSD 2-Clause License, the BSD 3-Clause License, and/or the Apache License, Version 2.0.
Licensor represents and warrants that no open-source component included in the Licensed Software is subject to any copyleft or reciprocal licensing obligation — including, without limitation, the GNU General Public License (GPL) v2.0 or v3.0, the GNU Lesser General Public License (LGPL), the Mozilla Public License (MPL), or any similar license — that would impose any obligation on Licensee to:
(a) disclose, publish, or make available the source code of any proprietary software developed by Licensee;
(b) license or distribute any proprietary software developed by Licensee under open-source or copyleft terms;
(c) grant any rights to any third party with respect to Licensee's proprietary software; or
(d) restrict Licensee's ability to charge license fees or otherwise commercially exploit Licensee's proprietary software,
including, without limitation, any Derivative Works (as defined in the MESLSA) developed by Licensee under Section 7.2 of the MESLSA or otherwise created through Licensee's integration, modification, or extension of the Licensed Software.
SECTION 8: ACCEPTANCE CRITERIA
8.1 Initial Delivery Acceptance
Licensor shall deliver the complete Licensed Software, including all components, deliverables, and documentation specified in Sections 1.2, 1.3, and 6.1 of this Exhibit A, to Licensee within fifteen (15) business days of the Effective Date of the MESLSA (i.e., no later than July 13, 2022).
The initial delivery of the Licensed Software shall be subject to the following acceptance criteria:
(a) All software components listed in Section 1.2(a) through (j) have been delivered to Licensee in complete, compilable source code form, together with all necessary header files, configuration files, linker scripts, and build system files required for successful compilation;
(b) The delivered source code successfully compiles without errors on at least one of the reference hardware platforms identified in Section 3.2 (MCT-RB-4200 or MCT-RB-4201) using at least one of the supported toolchains identified in Section 3.4, producing a functional executable image that boots and runs on the reference hardware;
(c) All documentation listed in Section 6.1 has been delivered in the formats specified in Section 6.2 and is complete, legible, and internally consistent with the delivered software version; and
(d) The Software Development Kit (SDK) described in Section 1.3(d) is functional and installable on standard development workstation environments (Windows 10/11, Ubuntu Linux 20.04/22.04, and macOS 12.x or later), and the SDK tools operate correctly with the delivered source code and reference hardware platforms.
Licensee shall have a period of thirty (30) calendar days from the date of delivery to perform acceptance testing against the foregoing acceptance criteria. Licensee shall notify Licensor in writing of acceptance or rejection within this thirty (30) calendar day period. If Licensee does not deliver written notice of rejection within the acceptance testing period, the initial delivery shall be deemed accepted.
8.2 Conformance to Specifications
The Licensed Software, as delivered and as updated during the Term, shall materially conform to the functional requirements and specifications set forth in Sections 2 and 4 of this Exhibit A. Material conformance means that the Licensed Software performs the functions described in Sections 2 and 4 in all material respects when operated in accordance with the documentation and on the supported hardware architectures and toolchains specified in Sections 3 and 6.
If Licensee identifies a non-conformance of the Licensed Software to the specifications set forth in Sections 2 and 4, Licensee shall report such non-conformance to Licensor in writing with sufficient technical detail to enable Licensor to reproduce and diagnose the reported non-conformance, including:
(a) a description of the expected behavior based on the applicable specification;
(b) a description of the observed behavior;
(c) the hardware platform, toolchain, and configuration used;
(d) steps to reproduce the non-conformance; and
(e) any relevant logs, diagnostic output, or test data.
Upon receipt of a properly documented non-conformance report, Licensor shall use commercially reasonable efforts to remedy any material non-conformance within sixty (60) calendar days of receipt of the report. Licensor shall provide Licensee with regular progress updates during the remediation period and shall deliver the corrected Licensed Software in accordance with the update delivery procedures set forth in Section 5.3. Licensor's obligation to remedy non-conformances is subject to the limitation that the non-conformance must be reproducible on a supported hardware platform using a supported toolchain configuration.
SECTION 9: RELATIONSHIP TO OTHER MESLSA EXHIBITS AND SCHEDULES
This Exhibit A is one of several exhibits and schedules attached to and incorporated into the MESLSA. The following cross-references identify the relationships between this Exhibit A and other MESLSA exhibits and schedules that are relevant to the Licensed Software:
(a) Exhibit B — Fee Schedule and Payment Milestones. Exhibit B to the MESLSA sets forth the complete fee schedule and payment milestones associated with the license grant, software delivery, maintenance and support services, and integration services contemplated by the MESLSA. Payment terms applicable to the initial delivery of the Licensed Software, Annual Maintenance and Support Fees (as referenced in Section 5.2.2 of this Exhibit A), and other financial obligations of the Parties are governed by Exhibit B.
(b) Exhibit C — Derivative Works Ownership and License-Back Terms. Exhibit C to the MESLSA governs the ownership, intellectual property rights, and license-back arrangements applicable to any modifications, adaptations, extensions, or derivative works of the Licensed Software created by Licensee's engineers during the integration of the Licensed Software into the Project Argonaut vehicle platform configurations. As of the Exhibit Effective Date, the Parties anticipate that Licensee's integration work will produce certain derivative works, currently designated as DW-001, DW-002, and DW-003, collectively comprising approximately forty-seven thousand (47,000) lines of source code. The ownership, license-back rights, and usage restrictions applicable to these derivative works are set forth in Exhibit C in accordance with Section 7.2 of the MESLSA.
(c) Statement of Work No. 1 — Integration Services for Project Argonaut. Statement of Work No. 1 attached to the MESLSA defines the scope, timeline, resource commitments, and deliverables for Licensor's integration support services in connection with Licensee's integration of the Licensed Software into the five (5) designated Project Argonaut vehicle platform configurations (Argonaut-A, Argonaut-B, Argonaut-C, Argonaut-D, and Argonaut-E). The BSP porting assistance obligations referenced in Section 3.3(c) of this Exhibit A, and the performance validation activities referenced in Section 4.4 of this Exhibit A, are further described in Statement of Work No. 1.
SECTION 10: DEFINITIONS SPECIFIC TO THIS EXHIBIT
The follow