Overhead Access Module (OAM) Project Series: CX90, CX91 Doc Number: NST-2025-00024NST-512873 These module requirement specifications (German: KLH) define the technical and procedural requirements for the provision of services related to the development and series production of components, subsystems, software, or integrated modules (collectively referred to as the "component" or "scope of supply") by the Integrator (supplier) for Novatra Systems or the relevant Novatra Operations Site (NOS) with which the Integrator has established a contractual supply agreement (hereafter referred to as the Client).NST-4764956 For reasons of linguistic simplicity, references to individuals may appear in the masculine form. All references, however, apply equally to persons of any gender identity.NST-467449 Within this document, the term “shall” is to be interpreted as equivalent to “must”.NST-467450 Together with the supporting documentation referenced herein, these specifications constitute the binding framework for the Integrator’s scope of supply.NST-467451 References to other documents are provided in square brackets, e.g. [LHV 310 00x]. Such documents are listed in the section “Other Applicable Documents.” Availability and retrieval options are managed through the Spec Vault Repository (SVR).NST-467457 This document is generated directly from the requirements management system maintained by Novatra Systems. Updates and revisions are managed in the same system and shared with the Integrator as necessary.NST-467454 Each content element is assigned a unique identifier (ID) for traceability. IDs may appear in the following formats depending on layout:• ID aligned left, text aligned right (requirement)• ID placed directly below the requirement text• ID shown in brackets after a headingNST-867453 The Integrator may also receive requirements through database export packages.NST-1079018 Italicized text within a PDF export indicates classification metadata associated with the requirement ID.NST-467458 The document “Common Requirements Pertaining to the Component Specifications” [LHV 310 00x] contains provisions that apply across all scopes of supply defined by Novatra Systems.NST-467462 In case of discrepancies between this specification and the Common Requirements [LHV 310 00x], the rules stated in this module requirement specification (KLH) shall prevail.NST-467459 Chapters or clauses in [LHV 310 00x] are referenced by their requirement ID rather than chapter numbering (e.g., “Scheduling in the Project” CRCS-3339913).NST-467460 CRCS-3339913 in the Common Requirements describes structural updates to the specification template. These serve as orientation guidance only and do not relieve the Integrator of the obligation to perform a thorough review of all applicable requirements.NST-467464 For each sourcing scope, the Integrator receives a corresponding Logistics Requirement Specification [LOG KLH], which defines the logistics concept. This concept may vary depending on the type of component, the applicable Novatra Operations Site (NOS), delivery format, and the Integrator Manufacturing Hub (IMH). The Integrator shall comply fully with the requirements outlined in [LOG KLH].NST-4750936 For each sourcing scope, the Client’s Purchasing Department provides a logistics framework. This framework is tailored by component type, supplier capability, and delivery location.NST-6750936 The components described in this section are part of the Celura Illumination Network (CIN) located within the vehicle’s roof module. Relevant system-level requirements applicable to these components are outlined in this chapter and shall be implemented by the Integrator accordingly.PV_LCH-43752 The LCH consists of a Prime Controller Node (PCN) and multiple Optic Flow Arrays (OFAs). The OFAs are subdivided into Sub-Light Processing Units (SLPUs), each of which manages assigned Trispectrum Emitters (TSEs).PV_LCH-43768 The LCH receives control instructions through the LNX Communication Layer (LNX- CL) and distributes the relevant information to the SLPUs, which then execute the commands.PV_LCH-43715 Colors are transmitted as Trispectrum (RGB) values. Each SLPU computes the required pulse-width modulation (PWM) for its TSEs using a correction algorithm to achieve calibrated color accuracy. The LCH and its SLPUs automatically interpolate incoming data at up to 100 fps.PV_LCH-43711 Target light images may be transmitted to the LCH and subsequently forwarded to the SLPUs. Execution can occur immediately or after preloading the image into an SLPU buffer memory, triggered later through a defined command.PV_LCH-43720 The PCN must be able to control a configurable subset of TSEs within the OFAs via the assigned SLPUs.PV_LCH-43739 Up to n SLPUs may be deployed. The number of TSEs (m) must be allocated using the parameter PALC_SLPU_number_[n]=[x y] (x>1, y≤m). Final agreement on the number and addressing of both SLPUs and TSEs shall be confirmed with the Client.PV_LCH-43760 The PCN transmits display commands to the relevant SLPUs. These are addressed according to the LNX-CL scheduling protocol and carry user data defined in subsequent chapters.PV_LCH-43744 For reliability, identical user data may be cyclically re-sent (e.g., every 500 ms) if no new instructions are available. The LCH or receiving SLPU must determine whether the data has already been received and whether it is present in its buffer or working memory.PV_LCH-43692 All required signals for LCH and SLPUs, along with their expected behavior, are specified in the associated .ldf file.PV_LCH-43698 The LCH is addressed via the LNX-CL schedule, with each SLPU allocated a dedicated data set.PV_LCH-43728 The LCH must evaluate the LNX-CL schedule to determine which SLPU-specific data is relevant for execution.PV_LCH-43705 Up to 16 SLPUs can be addressed simultaneously. Each must be assigned an individual fixed address (1…n).PV_LCH-43763 This addressing is configured via the parameter PALC_SLPU-n-address_[n]=[1…16].(Requirement reserved for addressing-specific definitions, already aligned with LNX-CL addressing scheme.)2.1.4.1.1.1.4 Control of Color (PV_LCH-13702) PV_LCH-43723 Color transmission occurs via the “Trispectrum color value” signal.PV_LCH-43713 The LCH must convert the received Trispectrum color value into the calibrated target color.PV_LCH-43762 Elementary color red shall be displayed at values = 4094/0/0, activating only the red chip of the TSE (uncalibrated).PV_LCH-43691 Elementary color green shall be displayed at values = 0/4094/0. PV_LCH-43755 Elementary color blue shall be displayed at values = 0/0/4094. PV_LCH-43689 An input value of 4095 is interpreted as IDLE.PV_LCH-43735 If an IDLE value is received, the LCH must disregard the corresponding command without interrupting ongoing operations.PV_LCH-43734 If a color value falls outside the set of valid IDs defined by the Client, the LCH must discard the command. Ongoing operations remain unaffected.2.1.4.1.1.1.5 Brightness Control (PV_LCH-43738) PV_LCH-43710 Brightness is controlled via the “Trispectrum brightness value” signal.PV_LCH-43745 The LCH shall perform linear interpolation between values transmitted by the PCN at 6.25 fps up to 100 fps.PV_LCH-43695 Interpolation can be enabled or disabled via the “Execution request” signal.PV_LCH-43743 Additional details on interpolation are provided in the technical lighting content section of the KLH.2.1.4.1.1.1.7 Memory Management (PV_LCH-43716) PV_LCH-43697 The LCH shall provide two distinct memory areas:PV_LCH-43766 Light images must be preloaded into the buffer memory independently of data in the executing memory.PV_LCH-43733 A command defined in the .ldf file shall be used to transfer preloaded images from the buffer into executing memory for display.PV_LCH-51002 Different execution types are available, defining how the LCH processes incoming instructions.PV_LCH-51003 The execution type is transmitted via the “Execution request” signal.PV_LCH-51005 When set to IDLE, the addressed LCH shall ignore all user data in the received request. Ongoing operations are not disrupted or modified.PV_LCH-51006 Note: The IDLE mode is primarily used for synchronization of individual sequences.PV_LCH-51008 All SLPUs shall transfer data stored in buffer memory into working memory and begin interpolated execution if the value = GLOBAL_INT. Any operation currently running is cancelled.PV_LCH-51010 All SLPUs shall transfer received data into buffer memory when the value = LOAD. Ongoing operations remain unaffected.2.1.4.1.1.1.8.4 NDEF & SNA (PV_LCH-51011) PV_LCH-51012 The LCH must interpret value range 2…3 as NDEF (Not Defined).PV_LCH-51013 If the value = NDEF/SNA, the LCH shall ignore or discard all information in the execution request. Ongoing operations remain unaffected.2.1.4.1.1.1.9 Initialization After Reset (PV_LCH-51014) PV_LCH-51015 After a restart, the LCH shall initialize buffer memory with the following values:• Trispectrum value = 0 / 0 / 0PV_LCH-51017 The time since the last valid message must be monitored. Each valid message resets the timer to 0.PV_LCH-51018 If the monitored time exceeds a configurable parameter (0…3600s, with 0 = timer disabled), the current function must be aborted, communication stopped, and the system switched to the lowest power state.2.1.4.1.2.1.1.1 Signal – Color Request (PV_LCH-51022) PV_LCH-51023 Description: Defines color/brightness request for the LCH.PV_LCH-51024 The corresponding 12-bit Trispectrum (R / G / B) values are transmitted via the signal: LCH_SLPU[01...16]RGB[Red/Green/Blue]_Rq.PV_LCH-51026 Description: Defines the execution mode for the LCH. PV_LCH-51027 The execution request is transmitted via the signal: LCH_OprtnCmd_Rq.PV_LCH-51029 The output interface is described in the KLH.NST-51035 Each function description contains preconditions, prerequisites, triggers, abort conditions, and end conditions.NST-51036 Precondition: A condition required before a function is initiated. It may not remain valid throughout execution. If invalidated, the function is not aborted.NST-51037 Functional prerequisite without triggering role: A condition that must hold true throughout execution but cannot trigger the function (e.g., system power state). If it becomes invalid, the function is aborted.NST-51038 Functional prerequisite with triggering role: A prerequisite that, in combination with a trigger, activates the function. If invalidated during execution, the function is aborted.NST-51039 Functional trigger: An event that initiates the function.• Flank-based: only on change (e.g., button press).• Status-based: constant condition (e.g., manual switch ON).NST-51040 Abortion condition: An explicit condition that aborts execution immediately (e.g., opposite command input).NST-51041 End condition: When fulfilled, the function terminates as planned (e.g., end position reached).NST-51042 Logical dependencies between conditions must be indicated (AND / OR).NST-51044 The component shall support multiple power states:1. Sleep Mode – All peripheral elements off, current consumption within sleep limits.2. On Mode – Component fully active; periphery powered, communication active, light sources enabled on request.3. Power Safe Mode – Activated if brightness = 0 for a duration defined in PLCH_PowerSafe_[t]. Non-essential submodules are shut down.a. Recovery to active mode must occur in <100 ms.b. Communication remains active unless LNX-CL enters sleep.c. If LNX-CL sleep occurs without timeout, the component also enters Sleep Mode.d. If LNX-CL timeout occurs, all periphery must shut down and enter Sleepe. Diagnostic mode entry from Power Safe Mode must be possible.4. Communication Off Mode – If brightness > 0 while LNX-CL is in sleep, the LEDs remain active in the last set color/brightness, while communication is off.a. A timer starts when LNX-CL enters sleep.b. If no valid LNX-CL message is received before PLCH_CoMtimeout_[t] expires, the system enters Sleep Mode.c. Every valid message resets the timer (including “idle” messages).d. Parameter PLCH_CoMtimeout_[t] is distinct from the standard LNX-CL timeout.e. Diagnostic mode entry from Communication Off Mode must be possible.NST-52002 The Integrator shall provide a valid Supplier-ID to the Client. If such an ID is not available, the Integrator shall independently apply for a Supplier-ID at the LNX Alliance and submit it to the Client after issuance.NST-52003 The component shall support a baud rate of 19.2 kbaud.NST-52004 Note: Timing intervals are defined to ensure that user actions are executed without perceptible delay.NST-52005 The component shall be capable of waking up within 200 ms from Sleep Mode to perform a requested actuation of the Optic Flow Arrays (OFAs).NST-52006 At the latest, the second Prime Controller Node (PCN) request in the functional schedule must be evaluated and executed.NST-52008 The component shall implement the LNX-CL signal interface in compliance with the current LDF (LNX description file) for the specific model series.NST-52010 During initial startup, each Photon Driver (PD) shall store its assigned address in non-volatile memory.NST-52011 If the selected PDs do not support non-volatile storage (e.g., state machine limitations), the following measures shall be implemented:NST-52012 Each time the component powers on (from Sleep, Power Safe Mode, or after interruptions), all PD addresses shall be re-initialized.NST-52013 During initialization, the internal master logic shall ensure that all PDs are properly addressed and synchronized.NST-52014 The expected number of PDs or communication slaves per OFA shall be derived from coding parameters and verified during initialization.NST-52015 If the detected PDs deviate from the expected count, the system shall broadcast a configuration error on the bus, and all light outputs shall be disabled.NST-52016 No Trispectrum Emitters (TSEs) shall activate during initialization, and no visual feedback is permitted.NST-52017 The Integrator shall design the electronic circuitry to prevent voltage dips at the PD power supply that could compromise initialization or addressing during operation.NST-52019 This function is triggered via the diagnostic interface. NST-52020 It shall be implemented as the DiagExec Service (DES-31).NST-52021 This function shall run as a synchronous routine, since execution may exceed 60 seconds.NST-52022 The routine shall only run if explicitly invoked via the diagnostic interface.NST-52023 If regular addressing is required, visual feedback shall only be provided when the diagnostic service is externally triggered with tester presence confirmed.NST-52025 An extended diagnostic session must be active.NST-52027 The routine shall be invoked through the diagnostic interface using the corresponding execution command (startRoutine).NST-52029 The PCN shall readdress all internal slaves or Photon Drivers on both left and right OFAs via the internal bus system.NST-52030 All monitoring functions must remain active during the routine.NST-52032 The function shall be aborted if a stopRoutine command is received via the diagnostic interface.NST-52035 If monitoring concludes with a fault, the respective failure signal shall be transmitted.NST-52036 After completing the initialization routine, the component shall provide visual feedback through the TSEs:• If successful: all TSEs illuminate GREEN at full brightness for 10 seconds.• If a fault occurs: all TSEs blink RED at full brightness, 0.5 Hz for 10 seconds.• If partial operation only is possible, the maximum available TSEs shall activate.NST-52037 The return value shall be sent when the addressing routine completes, though visual feedback may continue afterward.NST-52038 Definitions of the Trispectrum colors (GREEN, RED, BLUE) are described in Chapter 10229574: Lighting Function.NST-52042 All requirements for Trispectrum Emitters (TSEs) and their RGB values are valid only if TSEs are installed in the component.NST-52044 The positioning and design of the component, including integration, must be coordinated with the Client.NST-52045 The Integrator must align material and color properties of surrounding components (affecting optical performance) with the Client’s interface managers at the latest by blank release.NST-52046 Any surrounding materials affecting visibility must be coordinated with the development authority prior to blank release.NST-52047 All interfaces shall be validated. NST-52048 Carry-over interfaces must be validated for each release cycle.NST-52049 Design and development implementation must be coordinated with all adjacent modules.NST-52050 In the Client’s Cooperation Kickoff Meeting, milestones (e.g., blank or tool release) shall be coordinated to ensure overall vehicle timelines are met.NST-52052 Light sources must comply with AEC-Q automotive certification.NST-52053 Final light source selection (including binning) must be approved by the Client’s development team.NST-52054 Light source datasheet limits must not be exceeded. Real-world boundary conditions shall be validated with worst-case measurement data. Supporting documentation must be prepared.NST-52055 Light sources shall not emit radiation in the ultraviolet range.NST-52056 Light sources must be safeguarded against excessive self-heating and external heating.NST-52057 The design must allow replacement of a light source with an equivalent from another manufacturer (form, fit, and function).NST-52058 Second-source alternatives must be identified and validated without further modification.NST-52059 Production processes (e.g., pick-and-place vacuum pipettes) must be suitable for TSEs and approved by the emitter manufacturer.NST-52060 Lighting concepts shall prioritize designs that avoid additional calibration (brightness or color) during industrialization.2.1.5.1.6.1.3.1 Defect and Deactivation of Multi-Emitter Light Sources (NST-6359121) NST-6359122 Any defect occurring in the light source shall be reliably detected.NST-6359123 If a single emitter within a Trispectrum Emitter (TSE) or pixel is defective, this failure must be detected.NST-6359124 Following detection, the affected multi-emitter TSE / pixel shall be automatically deactivated.NST-6359125 Strategies for handling multiple defects shall be coordinated with the client (Novatra Systems).NST-6359131 The Integrator shall coordinate market-specific launch curves with Novatra Systems to align precisely with official rollout schedules.NST-6359132 The Integrator should deliver a new compiled software binary with every development loop.NST-6359133 If the Integrator deems it essential for project performance, it may appoint a resident engineer to facilitate knowledge transfer and provide on-site technical support at Novatra Operations Sites (NOS).NST-6359141 The Unified Cybersecurity Terms (UCT) shall be complied with. For execution of the assignment, diagnosis of security-relevant Prime Controller Nodes (PCNs) and Sub- Light Processing Units (SLPUs) requires Secure Access Credentials (SAC).NST-6359142 If the Integrator does not operate proprietary software for SAC management, the KeyMesh Manager (KMM) provided by Novatra Systems may be used as an alternative. NST-6359143 Both SAC and KMM are governed under the UCT framework, consisting of the following governing documents:• UCT for Secure Access Credentials [MSS 10916]• UCT for Key Mesh Manager [MSS 10917]NST-6359142 If the Integrator does not operate proprietary software for SAC management, the KeyMesh Manager (KMM) provided by Novatra Systems may be used as an alternative.NST-6359143 Both SAC and KMM are governed under the UCT framework, consisting of the following governing documents:• UCT for Secure Access Credentials [MSS 10916]• UCT for Key Mesh Manager [MSS 10917]Number of strips per rod (-) Total width mm Tape width mm 10 115 6 8 9 117 12 6 117 15 109 5 120 3 18 25 2 yTemperature Class Continuous service temperature 3000 H (T1) to (to) °C Short-term temperature 200h Tk (To+20) °C Overload Temperature Ta = (To+50) °C A -35 to 80 120 100 135 -35 to 90 B 115 120 140 -35 to 100 B (100 °C) 165 140 C -35 to 115 185 D -35 to 140 165 185 E 200 -35 to 160 6 8 % 3 6