module ara::shwa — Safe Hardware Acceleration

The adaptive cluster shwa provides a process-local library for the functionally safe control of heterogeneous compute accelerators such as GPUs and NPUs (AUTOSAR_AP_EXP_SWArchitecture p. 127). It enables device-agnostic selection of execution units, management of n-dimensional memory buffers, and asynchronous queuing of parallel compute tasks via execution queues ([AP_SWS_SHWA_00309], [AP_SWS_SHWA_00912]). In the event of task execution errors, no rollback semantics exist, which is why the affected buffer data is considered indeterminate modified ([AP_SWS_SHWA_00604]).

more ›

The functional cluster Safe Hardware Acceleration (shwa) provides a standardized, functionally safe execution model for heterogeneous compute units such as GPUs, NPUs, DSPs, and FPGAs for the AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_SWArchitecture p. 132). Implemented as an in-process library, shwa enables Adaptive Applications as well as other functional clusters to directly control high-performance compute resources with zero latency (AUTOSAR_AP_EXP_SWArchitecture p. 127, SWS_SafeHardwareAcceleration p. 23).

Hardware platforms and target devices are abstracted via Platform and Device ([AP_SWS_SHWA_01107], [AP_SWS_SHWA_00308]). Using strategy classes such as GpuSelector or AcceleratorSelector, applications can flexibly select suitable compute targets ([AP_SWS_SHWA_00407], [AP_SWS_SHWA_00413]). Data buffers are allocated via Buffer in N-dimensional index spaces (Range), while structured read and write accesses are performed type-safely via Accessor and Id ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00007], [AP_SWS_SHWA_00707]).

Sequence diagram: End-to-end sequence of buffer allocation, kernel submission (submit), and asynchronous synchronization. Sources: AP_SWS_SHWA_00209, AP_SWS_SHWA_00909, AP_SWS_SHWA_00912, AP_SWS_SHWA_00604.

Computation tasks are defined via TaskHandler as a single task or parallel loop and submitted to the device via queues (Queue) ([AP_SWS_SHWA_01203], [AP_SWS_SHWA_00912]). The return value provides an Event object for blocking or time-limited synchronizations ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00606]). Runtime monitoring is performed using DeviceMonitor, which maps the current hardware state (kReady, kNotAccesible, kFailure, kUnknown) ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_00103]).

Errors are reported deterministically via ara::core::Result and ShwaErrorCode ([AP_SWS_SHWA_01301]). If a task execution fails, the operations possess no rollback semantics, so linked buffers must be classified as indeterminately modified ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00914]).

more ›

Architectural Role and System Boundaries of Safe Hardware Acceleration

The functional cluster Safe Hardware Acceleration (shwa) provides a standardized, functionally safe execution and abstraction model for heterogeneous compute units such as GPUs, DSPs, NPUs, and FPGAs within the AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_SWArchitecture p. 132). In contrast to daemon-based platform clusters such as Platform Health Management, shwa is designed as a non-daemon-based, process-local library (in-process library) (AUTOSAR_AP_EXP_SWArchitecture p. 127). As a result, the runtime environment operates directly in the POSIX address space of the consuming user process and decouples computation tasks from the underlying accelerator drivers without IPC latencies (AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23).

The architectural interface design is aligned with modern standards for heterogeneous computing such as SYCL and OpenCL, but strictly adapts these paradigms to the deterministic and safety-oriented requirements of the AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15). Constructors of all primary interface classes are declared private; instances can be created exclusively via named static factory methods of type Create() (EXP_SafeHardwareAccelerationAPI p. 15). Almost all operations signal their success or system-specific error conditions via the return type ara::core::Result ([AP_SWS_SHWA_00308], EXP_SafeHardwareAccelerationAPI p. 15). In addition to regular Adaptive Applications, other functional clusters (for example, image processing or perception clusters) can directly integrate the C++ interfaces of shwa for highly parallel HPC workloads (SWS_SafeHardwareAcceleration p. 23).

Context diagram: Embedding of ara::shwa as an in-process library in the POSIX process space for controlling heterogeneous accelerators. Sources: AUTOSAR_AP_EXP_SWArchitecture p. 127, SWS_SafeHardwareAcceleration p. 22.

Hardware Topology, Platform Discovery, and Device Selection

The topology of the compute accelerators integrated into the overall system is abstracted via the interface Platform ([AP_SWS_SHWA_01107]). Via the static operation Platform::GetPlatforms(), the application first determines all registered execution platforms and subsequently queries the respectively assigned compute units using Platform::GetDevices() ([AP_SWS_SHWA_01108], AUTOSAR_AP_EXP_SWArchitecture p. 132). Each physical or logical execution target is represented in the system by an Device object ([AP_SWS_SHWA_00302]). An Device provides inspection methods for classifying the hardware type, including IsCpu() ([AP_SWS_SHWA_00310]), IsGpu() ([AP_SWS_SHWA_00311]), and IsAccelerator() ([AP_SWS_SHWA_00312]), as well as generic detail queries via the function template GetInfo() ([AP_SWS_SHWA_00313]).

For the targeted selection of suitable compute units, shwa provides the polymorphic selection pattern DeviceSelector ([AP_SWS_SHWA_00402], [AP_SWS_SHWA_00403]). Via the default implementations GpuSelector ([AP_SWS_SHWA_00406], [AP_SWS_SHWA_00407]), CpuSelector ([AP_SWS_SHWA_00409], [AP_SWS_SHWA_00410]), and AcceleratorSelector ([AP_SWS_SHWA_00412], [AP_SWS_SHWA_00413]), systems can filter compute targets according to predefined priorities or heuristic suitability ratings. The factory method Device::Create(deviceSelector) binds this selection mechanism directly to the device instantiation ([AP_SWS_SHWA_00309]).

Sequence diagram: Topology discovery, selection of a compute target, and instantiation of a logical device. Sources: AP_SWS_SHWA_01107, AP_SWS_SHWA_01108, AP_SWS_SHWA_00407, AP_SWS_SHWA_00309.

Memory Management and Multidimensional Data Access with Buffer and Accessor

For parallel compute operations on heterogeneous architectures, shwa strictly separates physical data storage from logical access (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15). Memory regions are encapsulated via the template Buffer<DataT, Dimensions, AllocatorT> ([AP_SWS_SHWA_00202]). The extent of a memory in one-, two-, or three-dimensional space is specified by the structure Range<Dimensions> ([AP_SWS_SHWA_01007], [AP_SWS_SHWA_01008], [AP_SWS_SHWA_01009]), whose dimensions can be queried via GetDimension0(), GetDimension1(), and GetDimension2() ([AP_SWS_SHWA_01010], [AP_SWS_SHWA_01011], [AP_SWS_SHWA_01012]). A buffer can either be created anew with its own memory or allocator ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00210]) or integrate existing host memory pointers (hostData) as input or output data ([AP_SWS_SHWA_00211], [AP_SWS_SHWA_00213], [AP_SWS_SHWA_00214]). Owning buffers are typically returned by Buffer::Create() as std::unique_ptr (EXP_SafeHardwareAccelerationAPI p. 15).

The actual read and write access to buffer data is not performed directly via pointers, but via typed Accessor objects ([AP_SWS_SHWA_00007], [AP_SWS_SHWA_00008]). The access mode is determined via the enum AccessMode, which comprises the values kRead, kWrite, and kReadWrite ([AP_SWS_SHWA_00101]). The addressing of discrete index points in N-dimensional space is performed by means of the type Id<Dimensions> ([AP_SWS_SHWA_00707], [AP_SWS_SHWA_00708], [AP_SWS_SHWA_00709]) with the corresponding coordinate getters and setters ([AP_SWS_SHWA_00710], [AP_SWS_SHWA_00711]). For manipulating individual array elements, Accessor provides the subscript operator operator[] ([AP_SWS_SHWA_00009], [AP_SWS_SHWA_00010]) as well as the synchronizing methods Get() ([AP_SWS_SHWA_00012]) and Set() ([AP_SWS_SHWA_00011]). By passing PropertyList instances, specific memory properties and access attributes can be attached declaratively ([AP_SWS_SHWA_00802], [AP_SWS_SHWA_00015], [AP_SWS_SHWA_00215]).

Task Definition, Job Scheduling, and Execution via Queues

The execution of computations on accelerator devices is coordinated via command queues of type Queue ([AP_SWS_SHWA_00902]). A Queue is bound via its factory method Create() to a specific Device or a DeviceSelector and optionally configured with a ErrorHandler as well as a PropertyList ([AP_SWS_SHWA_00908], [AP_SWS_SHWA_00909]). The method GetDevice() returns the compute device coupled to the queue ([AP_SWS_SHWA_00910]). The execution behavior of the queue can be verified via IsInOrder() ([AP_SWS_SHWA_00911]): In an in-order queue, queued computation tasks are processed strictly sequentially (AUTOSAR_AP_EXP_SWArchitecture p. 133).

The definition of concrete workloads is performed using TaskHandler ([AP_SWS_SHWA_01202]). The task handler distinguishes between atomic single tasks (SingleTask(), [AP_SWS_SHWA_01203]) and data-parallel compute grids (ParallelFor(), [AP_SWS_SHWA_01204]). The target of execution can be specified via the enumeration Target either as an accelerator (kDevice) or as a CPU host task (kHostTask) ([AP_SWS_SHWA_00102]). Submission to the queue takes place via the method Queue::Submit() ([AP_SWS_SHWA_00912]). For more complex pipelines, Submit() also supports specifying a secondary queue to map dependencies between different hardware pipelines ([AP_SWS_SHWA_00913], AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23).

Sequence diagram: End-to-end sequence of buffer allocation, kernel submission (submit), and asynchronous synchronization. Sources: AP_SWS_SHWA_00209, AP_SWS_SHWA_00909, AP_SWS_SHWA_00912, AP_SWS_SHWA_00604.

Event-Based Synchronization and Hardware State Monitoring

Each submission via Queue::Submit() returns an Event object that serves as an asynchronous synchronization anchor ([AP_SWS_SHWA_00912], [AP_SWS_SHWA_00602]). A caller can either wait for completion of the hardware computation in a blocking manner using Event::Wait() ([AP_SWS_SHWA_00604]) or perform a time-limited synchronization via WaitFor(ms) ([AP_SWS_SHWA_00606]). Multiple events can be monitored in aggregate via Event::Wait(const Vector<Event>&) ([AP_SWS_SHWA_00605]). Alternatively, the queue itself provides collective synchronization methods: Queue::Wait() blocks until all tasks queued so far have been processed ([AP_SWS_SHWA_00914]), while Queue::WaitFor(ms) limits waiting to a specified timeout ([AP_SWS_SHWA_00917]).

To ensure the reliability and functional safety of the hardware accelerators at runtime, shwa defines the monitoring component DeviceMonitor ([AP_SWS_SHWA_01402]). Instances are created via static Create() methods referenced to a Device or a DeviceSelector ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_01408]). The current hardware state is queried via the method DeviceMonitor::Status() ([AP_SWS_SHWA_01409]). The enumeration DeviceStatus comprises four standardized states: kReady (0, ready for operation), kNotAccesible (1, not accessible), kFailure (2, error state), and kUnknown (255, status cannot be determined) ([AP_SWS_SHWA_00103]). This monitoring mechanism forms the foundation for safety analyses and health monitoring according to ISO 26262 (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15).

State diagram: Lifecycle and status transitions of DeviceStatus according to ara::shwa::DeviceMonitor. Sources: AP_SWS_SHWA_00103, AP_SWS_SHWA_01409.

Behavior in Case of Error and Diagnostics

The error handling concept of shwa is based on the AUTOSAR-specific error domain ShwaErrorDomain ([AP_SWS_SHWA_01307]), which can be obtained via GetShwaDomain() ([AP_SWS_SHWA_01311]). Specific error codes are represented by the standardized enumeration ShwaErrorCode ([AP_SWS_SHWA_01301]). These include fundamental runtime errors such as kRuntime, computation aborts on the accelerator such as kTaskExecutionFailure, memory allocation errors such as kMemoryNotAllocated, memory integrity violations such as kIntegrityCorrupted, temporary resource conflicts such as kResourceBusy, and invalid access modes such as kInvalidAccessMode ([AP_SWS_SHWA_01301]). Error codes are constructed type-safely with MakeErrorCode() ([AP_SWS_SHWA_01312]) and provide textual descriptions via Name() and Message() ([AP_SWS_SHWA_01308], [AP_SWS_SHWA_01309]).

Errors during asynchronous execution or while waiting for events (Event::Wait() or Queue::Wait()) have severe effects on data consistency: If a kTaskExecutionFailure or kRuntime occurs during computation, the affected operations possess no rollback semantics and the data in the linked buffers are considered indeterminately modified ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00914]). For asynchronous notifications, the class ErrorHandler is used, whose callback is triggered by means of HandleError() ([AP_SWS_SHWA_00507], [AP_SWS_SHWA_00508]). If the application requires exception handling, errors can be converted into an ShwaException via ThrowAsException() ([AP_SWS_SHWA_01303], [AP_SWS_SHWA_01310]).

Further Detailed Evidence and Specification References

The architecture and requirements of cluster shwa are fully substantiated by normative requirements and associated explanatory documents. Table 1 summarizes the core concepts and their authoritative references.

Subject Area	Important Specification Elements	Evidence References
Architecture & Deployment	In-process library, functional classification in category Safety	AUTOSAR_AP_EXP_SWArchitecture S. 127, AUTOSAR_AP_EXP_SWArchitecture S. 132
Topology & Selection	Platform, Device, DeviceSelector, GpuSelector, CpuSelector	[AP_SWS_SHWA_01107], [AP_SWS_SHWA_00308], [AP_SWS_SHWA_00403]
Memory & Data Access	Buffer, Accessor, Range, Id, AccessMode	[AP_SWS_SHWA_00209], [AP_SWS_SHWA_00007], [AP_SWS_SHWA_01007], [AP_SWS_SHWA_00101]
Job Scheduling & Synchronization	Queue, TaskHandler, Event	[AP_SWS_SHWA_00908], [AP_SWS_SHWA_01202], [AP_SWS_SHWA_00604]
Hardware Monitoring & Errors	DeviceMonitor, DeviceStatus, ShwaErrorCode, ErrorHandler	[AP_SWS_SHWA_01407], [AP_SWS_SHWA_00103], [AP_SWS_SHWA_01301], [AP_SWS_SHWA_00507]

The typical pipeline instantiation and decoupling of multiple queues within an application is illustrated in detail in the specification (SWS_SafeHardwareAcceleration p. 22, AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23). The strict separation of memory and compute resources guarantees deterministic behavior in safety-critical automotive application domains (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15).