Method for scheduling element services within a distributed data streaming service framework

Abstract

A method of scheduling elemental services within a distributed dataflow service framework, the framework comprising: a host system-on-chip, SoC, having a standard core and an accelerator core; a sensing service providing input data comprising sensor data; elemental services processing the input data, wherein each elemental service comprises a common pattern having an algorithm for processing the input data, an element for encapsulating the algorithm into a generic encapsulator that makes the algorithm compatible with other algorithms, an element interface for encapsulating the element output into a generic interface that allows generic communication with other elemental services, and a configuration file comprising a scheduling policy to execute the elemental service; wherein the method comprises, for each elemental service, scheduling the execution of the elemental service using the scheduling policy, and executing each elemental service on the standard and / or accelerator core.

Description

Technical Field

[0001] This disclosure generally relates to the field of data stream applications utilizing the growing technologies of artificial intelligence (AI) and machine learning (ML) with the aim of ensuring the safety of people and the environment. In particular, this disclosure relates to the automotive field and to frameworks for automotive perception systems for use inside and / or outside vehicles, such as autonomous, semi-autonomous, or conventional vehicles.

[0002] More specifically, this disclosure relates to a method for scheduling the execution of a feature service within a distributed data streaming service "DDFS" framework. Background Technology

[0003] Many companies / consortia have researched and developed various AI / ML-based methods and algorithms for this goal. Careful selection and integration of these algorithms into today's automotive head units is necessary to optimally utilize these elements. Integrating and combining these algorithms into original equipment manufacturer (OEM) platforms in a standardized manner presents a challenge, as these algorithms come from different vendors using proprietary algorithms, data structure formats, or application programming interfaces (APIs). A common aspect is that these algorithms are data-driven and involve heavy processing of input data.

[0004] Databases such as OpenCV (https: / / opencv.org) provide real-time optimized computer vision libraries, tools, and hardware. It also supports model execution for machine learning and artificial intelligence.

[0005] Another database, such as OpenVX (https: / / www.khronos.org / openvx / ), is an open, royalty-free standard for cross-platform acceleration of computer vision applications. It is designed to facilitate portable, optimized, and power-efficient processing of methods used in vision algorithms.

[0006] The existing solutions mentioned do not address the problem of combining various algorithm implementations, which may come from different vendors and are based on custom algorithms, into a public platform.

[0007] Furthermore, the existing technical solutions do not address the use case of forming processing pipelines in distributed systems by connecting to AI / ML algorithms running on remote machines or kernels. Additionally, the existing solutions do not offer any flexibility in configuring processing rates to "schedule" optimal hardware usage. Moreover, the existing technical solutions cannot operate across the boundaries of virtualized (or hyper-virtualized) systems.

[0008] Existing public content needs to be improved to at least partially overcome the aforementioned shortcomings. Summary of the Invention

[0009] To address this problem, this disclosure proposes a method for scheduling the execution of feature services within a Distributed Data Streaming Service (DDFS) framework, the DDFS framework comprising a main system-on-a-chip (SoC) having a standard kernel and at least one accelerator kernel; at least one sensing service providing input data containing sensor data; and multiple feature services processing the input data, wherein each feature service has a common pattern for an algorithm for processing the input data, features for encapsulating the algorithm in a generic wrapper that makes the algorithm compatible with other algorithms from other feature services, feature interfaces for encapsulating the feature output in a generic interface that allows generic communication with other services, and a configuration file including a scheduling policy for executing the feature services; and wherein the method includes, for each feature service, - Use the scheduling policy of the configuration file to schedule the execution of the element services; and - Execute the element services on the standard kernel and / or at least one accelerator kernel.

[0010] This scheduling approach allows for the flexible and distributed deployment of elements, including classical or machine learning-based algorithms, in any data-flow application domain in a supervised and controlled manner. Furthermore, DDFS has the ability to configure services to be executed according to flexible scheduling policies. Services can be configured to run according to scheduling policies specified in their own configuration files; that is, each service can follow its own independent scheduling policy.

[0011] According to its advantages, each element service receives input data in the form of input frames, and for each element service to be executed, the scheduling strategy is a self-regulating scheduling strategy selected from one of the following: (i) free-run execution, processing an input frame whenever it becomes available; (ii) time-triggered execution at a fixed frame rate, where an input frame is processed at a given time interval; (iii) batch time-triggered execution, where queued input frames are processed in batches at given time intervals; (iv) batch frame-triggered execution, where queued input frames are processed in batches whenever a given number of input frames are queued; (v) time-triggered execution with fixed time boxes, where queued input frames are processed within fixed time boxes. These self-regulating scheduling strategies for execution services achieve a good trade-off between processing performance and latency. The scheduling strategies for different services are statically selected during design time to meet the framework performance requirements of a given platform (SoC) and set of element services.

[0012] According to an advantageous aspect, a chain of at least two element services from multiple element services forms a service pipeline, wherein the first element service in the chain receives input data from at least one sensing service, and wherein the output of each element service in the service pipeline, except for the last element service, is used as the input of the next element service in the chain. More advantageously, DDFS supports multiple sequential and independent service pipelines. Furthermore, it is advantageous that independent service pipelines share the same input data, and wherein multiple service pipelines share the same output. Due to the common patterns of element services (such as...) Figure 2 As shown, each element service is modeled as an independent execution unit with standard input and output interfaces, which allows element services to be chained together to form a pipeline.

[0013] According to an advantageous aspect, at least one element service includes an artificial intelligence / machine learning (AI / ML) algorithm, and the element service with the AI / ML algorithm is processed by at least one accelerator core. AI / ML algorithms requiring more resources are preferably processed on any accelerator core, while other services without AI / ML algorithms can be executed on a standard core, thus providing optimized use of available resources.

[0014] According to its advantages, the DDFS framework also includes a kernel controller / scheduler for controlling the execution of feature services and / or their execution rate; and / or a runtime ML controller for managing feature service access to AI / ML resources. The proposed framework ensures that growing sets of algorithms / features can be executed efficiently by distributing and orchestrating services within limited hardware resources and stringent requirements.

[0015] According to its advantages, the DDFS architecture includes multiple sensing services in the vehicle, where in-cabin and / or external sensors include at least one camera and / or at least one other sensor device.

[0016] According to its advantages, the DDFS framework supports communication with distributed feature services, including executing feature services on a host SoC running a host OS or guest OS; and / or executing feature services on at least one external SoC running a host OS or guest OS.

[0017] According to an advantageous aspect, each element service also includes a control interface connected to DDFS to start or stop the element service; and an input processing queue for queuing input frames from the at least one sensing service or from another element service.

[0018] According to its advantages, the input processing queue can be configured in one of the following ways: (i) queuing all, where all input frames are queued for processing; (ii) queuing the last, where only the last received input frame is retained; (iii) queuing the last N, where the last N received input frames are retained; (iv) skipping input frames, where only every Nth received input frame is retained. The framework supports various queuing strategies, allowing for flexible processing rates to optimally utilize allocated resources.

[0019] According to an advantageous aspect, the configuration file also includes element and algorithm-specific parameters; and / or input processing rate; and / or target kernel for executing AI / ML algorithms on any of the at least one accelerator kernel; and / or service interconnection corresponding to different implementations of element services; and / or inter-process communication "IPC", wherein the DDFS framework supports a flexible selection of IPC technologies.

[0020] On the positive side, the configuration files for feature services are modifiable without requiring recompilation. This approach to configuring feature services allows for an easy and flexible way to change the behavior of the services.

[0021] This disclosure also relates to a non-transitory computer-readable medium comprising program instructions for causing a processor to perform a method according to any of the foregoing aspects.

[0022] This disclosure also relates to a motor vehicle that includes the non-transitory computer-readable medium described above.

[0023] Other aspects and advantages will be disclosed in the detailed description below. Attached Figure Description

[0024] This disclosure and the embodiments suggested herein should be considered as non-limiting examples and will be better understood with reference to the accompanying drawings, in which: Figure 1 A schematic diagram of the Distributed Data Streaming Service (DDFS) framework is provided; Figure 2 An example of the structure of a feature service is shown; Figure 3 This is an example of a DDFS service pipeline; Figure 4 An example of fixed frame rate policy scheduling is shown; Figure 5 An example of time-triggered batch scheduling is shown; Figure 6 An example of frame-triggered batch scheduling is shown; Figure 7 An example of timebox scheduling is shown; Figure 8A and Figure 8B An example of the interaction between the DDFS kernel controller and services is shown; Figure 9 This shows another example of the structure of the DDFS service architecture. Detailed Implementation

[0025] This disclosure relates to a framework that allows for the flexible and distributed deployment of elements, including classical or machine learning-based algorithms, in any data-flow application domain in a supervised and controlled manner. Furthermore, the proposed framework ensures that ever-growing sets of algorithms / elements can be efficiently executed by distributing and orchestrating services within limited hardware resources and stringent requirements.

[0026] Figure 1 An overview of the proposed Distributed Data Streaming Service (DDFS) framework according to one aspect of this disclosure is shown. The various components of DDFS are designed as services. DDFS is preferably designed as a service-oriented architecture (SoA), which allows services to be presented in independent locations, such as on different kernels with high reusability and scalability of services and parallel processing.

[0027] The DDFS framework has a main system-on-a-chip (SoC) (1.1) and may include one or more external SoCs (1.14). The main SoC has a standard core (aka), a main central processing unit (CPU) (1.2), and at least one or more so-called accelerator cores (1.3), which are also called hardware accelerators, such as a graphics processing unit (GPU), a digital signal processor (DSP), or a neural processing unit (NPU).

[0028] The DDFS framework has a kernel controller / scheduler (1.4) that coordinates service execution. This controller / scheduler allows control over the execution rate of services. An ML runtime controller (1.5) exists to manage service access to AI / ML resources. Communication between services is accomplished via a high-speed message bus (1.8). Services can be categorized into two main types: sensing services that provide input data to DDFS and element services that process this data.

[0029] DDFS supports sensing services such as camera services (1.6) and / or additional sensor services (1.7). For automotive perception systems, sensing services connect to in-cabin sensors (also known as in-cabin sensing or in-cabin monitoring) and / or external sensors. Input source data is provided by the sensing service, such as camera services (1.6) for images or any other type of sensor (1.7) for other kinds of data. Sensing services can then be dynamically started and stopped at any time needed, making the framework highly flexible.

[0030] DDFS also supports one or more feature services that can run entirely on the CPU (1.2) on a main SoC (1.1), such as feature service 1 and feature service N shown (1.9; 1.12), or entirely on any accelerator core (1.3), such as feature service 2 shown (1.10), or partially on both the CPU and one or more accelerator cores, such as feature service 3 shown (1.11). In particular, for feature services that include AI / ML algorithms, preprocessing and postprocessing algorithms can run on the CPU, while the AI / ML portion of the algorithm runs on one (or more) accelerator cores, as they are better designed to handle these AI / ML types of algorithms.

[0031] From DDFS's perspective, there is no maximum limit to the number of services supported by a perception service or feature service. The limit is given by the target platform, and DDFS is aware of these resources, enabling it to manage them effectively.

[0032] DDFS also supports communication with distributed services (1.15) running on one or more external SoCs (1.14) via a message bus (1.13), making DDFS a highly scalable solution.

[0033] DDFS also enables services running in virtualized environments to access underlying resources (such as AI / ML), because DDFS can execute on the host operating system "OS," while services execute within the guest OS (see...). Figure 9 ).

[0034] DDFS Service Model: Design and Use

[0035] Figure 2 The structure of a feature service is shown, consisting of six main parts: a control interface (2.1), encapsulated features (2.2), one or more algorithms (2.3), a feature interface (2.4), input and output processing queues (2.5a; 2.5b), and a configuration file (2.6). Each feature service is designed to provide one or more features. These features provide a final or intermediate output as input to another feature service, which further processes these results and produces new outputs.

[0036] The control interface (2.1) acts as a connection to DDFS. This part implements and supports the control interface defined by DDFS. With the help of this control interface, the framework can manage services, such as starting or stopping services.

[0037] The encapsulation element (2.2) encapsulates the underlying algorithm (or software development kit) "SDK" of the element that provides the service (or a portion thereof). Since algorithm vendors are not bound by standardized API methods, the element components of the element service act as a generic encapsulation to provide a streamlined view to the outside of the service. In this way, the kernel controller / scheduler (1.4) part is unaware of the internal details of the vendor's API.

[0038] Algorithm (2.3) is a data processing algorithm that can be based on classical or machine learning (AI / ML) methods (e.g., face detection, drowsiness detection, etc.). Figure 1 As shown, the DDFS framework can have multiple target accelerator kernels, such as GPUs, DSPs, and NPUs, to execute the AI / ML model of the algorithm. Feature services can be configured to select any of the target accelerator kernels (1.3). If no accelerator kernel is available, feature services can execute on a standard kernel (CPU).

[0039] The feature interface (2.4) encapsulates the output of the algorithm (2.3) into a generic interface independent of the underlying vendor API. This allows for communication with other feature services and general DDFS. Furthermore, this structure allows modification of internal features (encapsulating features and algorithms) without altering their feature interface, thus not affecting other feature services within the framework that depend on that interface.

[0040] The input processing queue (2.5a) serves as a buffer for the input data stream entering the service. The system's input data stream is independent of the service's processing rate. Therefore, each service is designed to have its own input queue, which is filled when the service is busy processing input. The framework supports various queuing strategies, allowing for flexible processing rates to optimally utilize allocated resources. Similarly, an optional output processing queue (2.5b) is used as a buffer for the output data stream flowing out of the service. More specifically, the output processing queue can be configured to be skipped when a feature service is executed alone or as the last feature service in a pipeline.

[0041] The configuration file (2.6) specifies the parameters that define how the service should run. Service configuration can be modified without recompiling the service. This method of configuring services allows for an easy and flexible way to change the behavior of a service. The following items are configurable aspects of a service: a. Specific parameters of elements and algorithms; b. Input processing rate; c. Scheduling strategy; d. Target accelerator kernels (e.g., GPUs, DSPs, NPUs) used to execute AI / ML algorithms; e. Service interconnection (basically another service with a matching interface) corresponding to different implementations of the same elements can be introduced by changing the configuration. f. Inter-process communication for supporting flexible selection of IPC technologies supported by the framework.

[0042] DDFS service pipeline

[0043] In the DDFS framework, at least one sensing service and several feature services have the potential to form a pipeline by feeding the output of one feature service as input to subsequent feature services. The sensing service provides input data to the first feature service in the chain that forms the pipeline.

[0044] Figure 3 Examples of two parallel pipelines (3.2 and 3.3) are shown. Each pipeline receives input data streams from one or more sensing services. In the presented examples, each pipeline (3.2; 3.3) includes a sensing device, namely a camera service (3.1), which provides input image frames, subsequently formed by a chain or sequence of three feature services (service 1–service 3; service 4–service 6). Communication between asynchronous services is performed via messages in a fast communication bus (3.4) by interconnecting these feature services to a bus that supports multi-client communication (i.e., the output of one feature service serves as input to multiple other feature services).

[0045] Pipelines allow for the creation of complex elements, such as in-cabin sensing (e.g., drowsiness detection), by combining selected sensing devices and specific element services. DDFS defines common patterns for element services (e.g., ...). Figure 2 As shown in the figure, each feature service is modeled as an independent execution unit with standard input and output interfaces, which allows feature services to be chained together to form a pipeline.

[0046] In DDFS, pipeline use cases can include one of the following: supporting multiple sequential parallel pipelines; independent pipelines can share the same input (joint input); multiple pipelines can share the same output (branched output); dynamically inserting / removing services from a pipeline without restarting; and enabling configurability of the pipeline's execution / processing rate by configuring the (sensing and feature) services that form the pipeline.

[0047] DDFS service scheduling

[0048] DDFS has the ability to configure the services to be executed according to flexible scheduling policies. DDFS services can be configured to run according to the scheduling policies specified in their own configuration files; that is, each service can follow its own independent scheduling policy. Services support different scheduling policies. The first type of scheduling policy is self-regulating scheduling. The second type of scheduling policy is framework-regulated scheduling.

[0049] One scheduling strategy in the first category is the so-called free-running strategy, where a service is allowed to run freely, so that it can begin processing the necessary input as soon as it becomes available. This is the simplest (default) case, where the only influencing factor is the scheduling strategy of the underlying OS (master, guest, or distributed OS).

[0050] Another scheduling strategy in the first category is time-triggered at a fixed frame rate. Using this strategy, services are triggered at given time intervals (periods or execution intervals), and they process a single input frame. Figure 4 An example of a fixed frame rate strategy is shown. Once the service is triggered (4.1), it processes a single input frame (4.2). After processing the input frame, the service remains interrupted (4.4) until it is triggered again. The service is then triggered again at a fixed execution interval (4.3), which is defined by the target frame rate provided in the service configuration file.

[0051] Another scheduling strategy in the first category is time-triggered batching. This scheduling strategy is a generalization of the fixed frame rate strategy because it allows a given number of frames to be executed once the service is triggered. Figure 5 An example of this strategy is shown. In this example, a fixed number of frames, such as three frames (5.2), are processed each time the service is triggered (5.1). However, if fewer frames are available, only those available frames are processed (5.3), so there is no guarantee that a given number of frames will be processed each time the service is executed. In this strategy, the execution interval is constant (5.4) and is independent of the number of frames processed.

[0052] Another scheduling strategy in the first category is batch frame triggering. In this strategy, the service is triggered when a given number of input frames in the queue are ready to be processed. Figure 6 An example of batch processing is shown. In the presented example, the service is triggered (6.1) when there are three frames (6.2) ready to be processed in the input processing queue. Once the frames are processed, the service remains interrupted (6.4) until a new batch of input frames (three in the presented example) becomes available. In this strategy, a fixed number of frames are guaranteed to be processed each time the service is triggered. However, the execution interval (6.3) can vary depending on the availability of input frames.

[0053] Another scheduling strategy in the first category is time-triggered scheduling using time boxes. In this strategy, the service can run at regular intervals for a given period of time, called a time box. Within each time box, the service can process one or more input frames until the time box (or window) expires. Therefore, there is no guarantee that a given number of frames will be processed. Figure 7 An example of timebox scheduling is shown. Each time a service is triggered (7.1), a timebox (time window) begins (7.3). In the example presented, three (7.2) and two (7.4) frames are processed within a timebox. The execution interval of a timebox is constant (7.5), but does not necessarily correspond to the timebox. Once a timebox ends, the service remains interrupted (7.6) until the service is triggered again. If the internal execution is the same as the timebox, there is no interruption time.

[0054] The self-regulating scheduling strategies (Type 1) for triggering services, as explained above, are generally sufficient to achieve a good trade-off between processing performance and latency. In this case, scheduling strategies for different services are statically selected during design time to meet the performance requirements of a given set of sensed and feature services. However, for a more dynamic scenario, frame-regulated scheduling of services (Type 2) is possible through a kernel scheduler (1.4) capable of managing the complete execution of services. This kernel scheduler is responsible for ensuring that all services reach the specified frame rate.

[0055] Figure 8A and Figure 8B An example of the interaction between the DDFS kernel controller / scheduler (8.1) and services (8.3) is shown. The kernel controller / scheduler can directly control the execution of services via the control interface (8.2). The control interface (8.2) allows the framework to start, stop, and even change the configuration of each service. The framework can determine the frequency and timing of service (8.4) activity via the kernel controller / scheduler.

[0056] DDFS queue configuration

[0057] The input (or output) processing queue for each service can be configured independently. In the so-called "Queue All" configuration, the queue is used in default mode, where all inputs are queued for processing. If the queue is full before the service is executed and queued frames need to be cleared, the queue is managed in FIFO (First In, First Out). In another configuration, the so-called "Queue Last," the queue ensures that only the latest input is held. When a new input frame is received, older input frames are discarded. Another configuration, the so-called "Queue Last N," is an extension of the "Queue Last" mode, ensuring that the queue only holds a fixed number of the most recent inputs. When a new input frame is received, older input frames are discarded. Yet another configuration, the so-called "Skip Input," ignores one or more inputs and does not add them to the queue at all, resulting in only every Nth input being queued.

[0058] Figure 9 Another example of the architecture of a DDFS service in a hypervised environment is shown. The virtualized environment has a primary domain (9.1), one or more guest domains (9.4), and a hardware platform (9.9). This framework enables services running in the virtualized environment to access underlying resources (such as AI / ML) because DDFS can execute on the primary operating system "OS," while the services execute within the guest OS.

[0059] The main domain (9.2) includes some element services 1…N (9.2) that will be executed on the main OS, the kernel controller / scheduler (9.3), the message bus (9.7), and the ML runtime controller (9.8) that connects the services to the hardware platform (9.9).

[0060] The guest domain (9.4) also includes some element services 1…N (9.5) that will be executed on the guest OS, and its kernel controller / scheduler (9.6) connected to the ML runtime controller (9.8) via the message bus (9.7).

[0061] The hardware platform (9.9) includes a standard core (such as a CPU) and one or more accelerator cores (such as a GPU, DSP, NPU, etc.).

[0062] The various implementations of this disclosure offer several key advantages, including: flexible scaling and adaptation to various platforms with different capabilities simply by changing service configurations; high service configurability in frame rate, queue size, processing kernel, IPC, etc.; distributed deployment of services within the framework; ease of establishing processing chains / pipelines from distributed services; ease of integration into hardware / software loops, and HIL / SIL testing; dynamic plug-and-play replacement / introduction / removal of services in the pipeline; simple and encapsulated high-level integration of algorithms from multiple vendors within DDFS; high reusability by encapsulating the internal details of algorithms from external systems; high portability of services across operating systems and hardware platforms; high scalability because the framework supports simple, standalone services up to processing chains involving several services (limited only by the capabilities of the underlying hardware and software platforms); and enabling services running within guest operating systems in virtualized (hyper-virtualized) environments to effectively access the underlying hardware.

[0063] This disclosure also relates to a non-transitory computer-readable medium including program instructions for causing a processor to perform a method for scheduling the execution of element services within a DDFS framework, according to any implementation thereof or any possible combination thereof.

[0064] The term "non-transitory" does not exclude legitimate tangible temporary storage media, such as flash drives or any rewritable storage media. Generally, computer-accessible media can include any tangible or non-transitory storage media or memory media, such as electronic, magnetic, or optical media. Such media can be optical discs, CD / DVD-ROMs, or any other media that can be connected to the DDFS framework via a dedicated communication interface or one of the publicly available interfaces. Alternatively, such media can reside, for example, permanently within the DDFS framework.

[0065] The terms “tangible” and “non-transitory” as used herein are intended to describe computer-readable storage media (or “memory”) that exclude the propagation of electromagnetic signals, but are not intended to otherwise limit the type of physical computer-readable storage device contained in the phrase “computer-readable medium” or “memory.” For example, the terms “non-transitory computer-readable medium” or “tangible memory” are intended to cover types of storage devices that do not necessarily store information permanently, including, for example, random access memory (RAM) and flash memory. Program instructions and data stored in a non-transitory form on a tangible computer-accessible storage medium can also be transmitted by transmission media or signals, such as electrical signals, electromagnetic signals, or digital signals.

[0066] This disclosure also relates to a motor vehicle including a non-transitory computer-readable medium that performs methods for scheduling element services within a DDFS framework. More specifically, this disclosure relates to a framework for automotive perception systems (e.g., for internal sensors, also known as in-cabin sensing or in-cabin monitoring, and / or for external sensors of the vehicle).

[0067] While an overview of the subject matter of the invention has been described with reference to specific exemplary embodiments, various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the embodiments disclosed herein.

Claims

1. A method for scheduling the execution of feature services within a Distributed Data Streaming Service (DDFS) framework, wherein the DDFS framework includes: - A main system-on-a-chip (SoC) with a standard core and at least one accelerator core; - Provide at least one sensing service that includes input data containing sensor data; - Multiple feature services that process the input data, wherein each feature service includes a common pattern having an algorithm for processing the input data, a feature for encapsulating the algorithm into a generic wrapper that makes the algorithm compatible with other algorithms from other feature services, a feature interface for encapsulating feature output into a generic interface that allows generic communication with other feature services, and a configuration file including a scheduling strategy to execute the feature service. The method includes providing services for each element: - Use the scheduling policy in the configuration file to schedule the execution of the element service; - Execute each element service on the standard kernel and / or the at least one accelerator kernel.

2. The method according to claim 1, wherein, Each feature service receives input data in the form of an input frame, and wherein, for each feature service to be executed, the scheduling strategy is selected from one of the following: - Runs freely, processing each input frame whenever it becomes available; - Time-triggered execution at a fixed frame rate, wherein an input frame is processed at a given time interval; - Batch time-triggered execution, where queued input frames are processed in batches at given time intervals; - Perform batch frame-triggered execution, and process the queued input frames in batches whenever a given number of input frames are queued. - Time-triggered execution is performed using fixed time boxes, where queued input frames are processed within the fixed time boxes.

3. The method according to claim 1 or 2, wherein, A service pipeline is formed by at least one sensing service and a chain of at least two element services from the plurality of element services, wherein a first element service in the chain receives input data from the at least one sensing service, and wherein the output of each element service in the service pipeline, except for the last element service, is used as the input of the next element service in the chain.

4. The method according to claim 3, wherein, The DDFS supports multiple sequential and independent service pipelines.

5. The method according to claim 4, wherein, Independent service pipelines share the same input data, and multiple service pipelines within them share the same output.

6. The method according to claim 1, wherein, At least one element service contains an artificial intelligence / machine learning (AI / ML) algorithm, and the element service with the AI / ML algorithm is processed by the at least one accelerator kernel.

7. The method according to claim 1, wherein, The DDFS framework also includes: - A kernel controller / scheduler for controlling the execution of the feature services and / or the execution rate of the feature services; and / or - Runtime ML controller, used to manage the feature services' access to AI / ML resources.

8. The method according to claim 1, wherein, The DDFS framework includes multiple sensing services in the vehicle, among which in-cabin sensors and / or external sensors include at least one camera and / or at least one other sensor device.

9. The method according to claim 1, wherein, The DDFS framework supports communication with distributed feature services in virtualized environments, including executing feature services on systems using the underlying resources of the hardware platform: - The main SoC running the host operating system (OS) or guest operating system; and / or - At least one external SoC running a host OS or a guest OS.

10. The method according to claim 1, wherein, Each element service also includes: - A control interface for connecting to the DDFS to start or stop the feature service; - An input processing queue for queuing input frames from at least one sensing service or from another element service.

11. The method according to claim 10, wherein, The input processing queue is configured in one of the following ways: - Queue all, where all input frames are queued for processing; - Queue the last one, where only the last received input frame is retained; - Queue the last N frames, keeping the last N received input frames in place; - Skip input frames, where only the Nth received input frame is retained.

12. The method according to claim 1, wherein, The configuration file also includes: - Element and algorithm-specific parameters; and / or - Input processing rate; and / or - Target standard and / or accelerator kernels for AI / ML algorithm execution; and / or - Service interconnection corresponding to different implementations of the aforementioned element services; and / or - Inter-process communication (IPC), wherein the DDFS framework supports flexible selection of IPC mechanisms.

13. The method according to claim 1, wherein, The configuration file for the element service can be modified without recompiling.

14. A non-transitory computer-readable medium comprising program instructions for causing a processor to perform the method according to any one of claims 1 to 13.

15. A motor vehicle comprising the non-transitory computer-readable medium according to claim 14.

Images