Continuous data processing with modular

Abstract

In various embodiments, a device may include at least one hardware processor; and a pipeline data processor implemented on the at least one hardware processor, the pipeline data processor comprising at least one source module for providing at least one continuous data stream to the one or more processing pipelines, and at least one receiving module for inputting data from the one or more processing pipelines; wherein the pipeline data processor comprises a plurality of different paths extending through the plurality of pipeline analysis modules; wherein the input path is only forward, and the input of one pipeline analysis module of the processing pipeline is required to be output by another earlier pipeline analysis module in the processing pipeline or at least one source module. Other embodiments may be disclosed and / or claimed.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to U.S. patent application No. 17 / 737,709, filed on May 5, 2022, the entire contents of which are incorporated by reference into this application.

[0003] Copyright Notice

[0004] ©2022 Airbiquity Inc. Portions of this patent document disclosure contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 37 CFR §1.71(d). Technical Field

[0005] Embodiments of the present disclosure relate to the field of continuous data processing, and in particular, to methods and apparatus associated with continuous data processing using a modular pipeline. Background Art

[0006] Continuous data processing involves capturing data as it becomes available, filtering or modifying it, and then forwarding it for further processing; all of this is done one datum at a time. This is different from aggregate data processing (such as that performed using a database or file), in which the entire data set is known before processing begins, and the data may be processed in multiple passes. In other words, while continuous data processing may be able to preserve some values ​​or parts of previous data while processing the current data, it cannot yet reference data that has not yet become available. In addition, this processing is continuous, meaning that there may be no effective "end" to data processing, and processing can continue as long as data is available. Finally, the timing and amount of data to be processed may be unpredictable, and processing may occur sporadically or frequently, processing one or more datums at a time. These facts mean that many existing tools and methods for processing large amounts of data cannot be applied to continuous data processing. Summary of the invention

[0007] The following is a summary of the invention in order to provide a basic understanding of some aspects of the present invention. This brief description is not intended to identify the important / critical elements of the present invention or to define the scope of the present invention. Its only purpose is to present some concepts of the present invention in a simplified form as a prelude to a more detailed description later.

[0008] Some known approaches to continuous data processing on devices with one or more digital processors may result in non-reusable and non-modular code, and limited interconnectivity between devices. Various embodiments utilizing modular continuous data processing may include processors, pipelines, and modules to provide a conceptual and runtime framework to enable modular and reusable software development and cross-platform and highly interconnected implementations. Various embodiments may provide a simple conceptual framework for understanding and implementing highly complex data analysis systems with:

[0009] ·Strong emphasis on modularization, decomposing functions into:

[0010] o Source modules, which obtain data from outside the processing unit, for example, access data from an external software source, read data from a file, capture data from a hardware sensor, or generate data based on internal state, or a combination of the above;

[0011] o Pipeline analysis modules, which are arranged in a pipeline to process data in stages; and

[0012] oSink module, which sends data from the processing unit for further processing;

[0013] Mapping rules apply to:

[0014] oSource to pipeline;

[0015] oA pipeline analysis module from a pipeline input or any previous module in the pipeline;

[0016] o pipeline analysis modules to pipeline outputs (which can be executed selectively - where pipeline analysis modules can act as filters);

[0017] oPipeline to receiver;

[0018] oMapping module for pipeline data processor:

[0019] 1 to N "source modules" that take one or more data types using whatever method is required, and "pump" that data into any pipeline through any module that inputs that data type;

[0020] 1 to N "pipelines", each pipeline consisting of 1 to N "pipeline analysis modules" that input one or more data types and output one or more data types, using mapping rules that allow bypassing of subsequent or previous modules; and

[0021] 1 to N "receive modules" that map to one or more data types at the output of the pipeline and forward that data using whatever method is required;

[0022] If two different modules may produce the same data type, but a given application requires data from only one of the modules (e.g., video data may be provided by the front-facing camera or the rear-facing camera, but the application may only require video data from the front-facing application), then the data type mapping may be module-specific.

[0023] Multiple pipelines share the same sources and sinks; and / or

[0024] Designed to take advantage of multi-processor / multi-core applications, yet be able to run on systems with limited resources.

[0025] Additional aspects and advantages of the present invention will become apparent from the following detailed description of preferred embodiments which proceeds with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 A system including a pipelined data processor host to provide sequential data processing according to various embodiments is schematically illustrated.

[0027] Figure 2 A system for providing continuous data processing using devices interconnected by a client internal network according to various embodiments is schematically illustrated.

[0028] Figure 3 A package that may be deployed on one or more devices to provide continuous data processing on the devices is schematically illustrated according to various embodiments.

[0029] Figure 4 Encapsulation that may be deployed on a single device to provide continuous data processing on the single device is schematically illustrated according to various embodiments.

[0030] Figure 5 Encapsulation that may be deployed on an interconnect device to provide continuous data processing on the interconnect device according to various embodiments is schematically illustrated.

[0031] Figure 6 A forward-only pipeline is schematically illustrated to provide sequential data processing according to various embodiments.

[0032] Figure 7 A single pipeline data processor for providing sequential data processing according to various embodiments is schematically illustrated.

[0033] Figure 8 A multi-pipelined data processor for providing sequential data processing according to various embodiments is schematically illustrated. DETAILED DESCRIPTION

[0034] In the following detailed description, reference is made to the accompanying drawings which form a part of this document, wherein the same reference numerals always indicate the same components, and wherein embodiments that may be implemented are shown by way of example. It should be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description should not be considered restrictive, and the scope of the embodiments is defined by the attached claims and their equivalents.

[0035] Various operations may be described as multiple discrete actions or sequential operations, described in a manner that is most helpful for understanding the claimed subject matter. However, the order of description should not be interpreted as implying that these operations must rely on the order. In particular, these operations may not be performed in the order presented. The operations may be performed in an order different from the described embodiment. In additional embodiments, various additional operations may be performed and / or the operations may be omitted.

[0036] The terms "substantially," "approximately," "substantially," "approximately," and "about" generally refer to within + / - 10% of a target value. Unless otherwise specified, the use of ordinal adjectives "first," "second," and "third," etc., to describe a common object merely indicates that different instances of similar objects are referred to and does not imply that the objects described must be arranged in a given order, whether temporal, spatial, ranked, or any other order.

[0037] For purposes of this disclosure, the phrases "A and / or B" and "A or B" mean (A), (B), or (A and B). For purposes of this disclosure, the phrases "A, B, and / or C" mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

[0038] The description may use the phrases "in one embodiment" or "in an embodiment," which may each refer to one or more of the same or different embodiments. In addition, the terms "comprising," "including," "having," etc. are synonymous when used with respect to embodiments of the present disclosure.

[0039] Continuous data processing can be performed as close to the source (i.e., where the data first becomes available for digital processing) as possible. This has a number of advantages, including that the digital processor may have limited external connectivity and may not be able to process the raw data being sent at a high rate. However, in many cases, the digital processor at the source also has limited computing resources and must perform such processing without delaying data capture, causing data loss, or interfering with other processing. Therefore, it is best to perform continuous data processing using the minimum computing resources and without interfering with any other operations being performed by the digital processing device.

[0040] Software for this serial processing has been created as one-off implementations that may be specific to the digital processor and its environment and are monolithic rather than modular. In the best case, code reusability is achieved using libraries for heavy math processing or system resources; but the structure of such applications is single-path, along the following lines: (1) read data; (2) process data, possibly using library functions; (3) send data if (2) results in output; and (4) go to (1).

[0041] Achieving higher levels of modularity requires some kind of supporting framework and scheme for creating and managing data types, processing modules, inputs and outputs, etc. For the specific purpose of continuous data processing, there are very few existing implementations of such frameworks, none of which meets all of these criteria. There are even fewer such framework implementations in the specific case of continuous data processing on resource-constrained digital processors.

[0042] Various embodiments described herein satisfy one or more of the following features:

[0043] Highly modular, and implemented in a way that encourages “composable” systems assembled from simple pre-written modules;

[0044] Highly portable: the same module can be run on any device, from limited process control devices with minimal CPU and RAM

[0045] to high-performance systems with powerful operating systems and no resource constraints;

[0046] Allow non-portable implementations when the use case requires it;

[0047] Can be implemented when required without interfering with other processing;

[0048] Provide the highest data throughput with the least possible resource usage;

[0049] Ability to process multiple types of data simultaneously; and / or

[0050] Ability to take advantage of interconnected systems containing multiple digital processors while remaining efficient on systems with a single digital processor.

[0051] An existing high-volume data processing model, called "MapReduce" (https: / / en.wikipedia.org / wiki / MapReduce), can be applied to continuous data processing. MapReduce processes large amounts of data by "mapping" a large dataset to a single function, which "reduces" that data to output. Note that mapreduce has similar limitations as continuous data processing - the reduction function cannot access subsequent data while processing the current data.

[0052] Mapreduce works by first limiting the entire data set to the smaller data set you want to reduce, this is the "map process", which filters and sorts the data. The data is then sent to a "reduction function", which aggregates the data or otherwise uses it to create the output data. Mapreduce is very efficient at processing large amounts of data, it breaks up the map data and distributes the "reduction operation" across multiple machines and processes the data in parallel. It also encourages the creation of very simple reduction functions, rather than creating large, complex implementations.

[0053] However, applying map-reduce alone to sequential data processing does not in itself provide modularity; rather, it is just another way to create monolithic applications that is not much different from existing common practices. Moreover, a single reduction function is either too simple or too complex for many use cases. In fact, most "big data" map-reduce implementations typically use multiple passes to perform anything but the simplest computations; the output of one pass is then map-reduceed again in another pass using a different map procedure and reduce function.

[0054] Another existing data processing model is the "data pipeline" (https: / / en.wikipedia.org / wiki / Pipeline(computing)). A data pipeline may include multiple modules, where data is read into one module, the output of that module is read into the next module, and so on.

[0055] Combining these models together might result in the following data processing model:

[0056] 1. Read data and be able to filter (map) based on some rules

[0057] 2. Process (reduce) data step by step through a pipeline consisting of 1 to N modules:

[0058] a. Send data to module 1

[0059] b. If module 1 produces output, send the data to module 2

[0060] c. If module 2 produces output, send the data to module 3

[0061] d.……

[0062] e. If module N produces output, send the data out of the pipeline

[0063] 3. If the pipeline produces output, send the data

[0064] 4. Go to (1)

[0065] However, this simple pipeline model has the following limitations: (a) it is completely linear; and (b) it does not provide enough "mapping". Following this model too strictly can lead to highly specialized and tightly coupled (meaning "less reusable") modules, and the simplest way to apply it is to create a single module that does everything, i.e. a monolithic approach. There are other problems, including that a digital processor may have many data types that can be processed, which do not fit into a single pipeline, and creating a single method to perform the filtering / mapping step may limit the use cases to which it can be applied.

[0066] Some embodiments described herein may apply the concept of data mapping to multiple locations throughout a pipeline model, not just at the input location.

[0067] First, modules in a pipeline do not require the output of the module that directly precedes them to be processed. Instead, a pipeline can map incoming data from a source to any module in the pipeline, not just the first, and can map outputs from any module to the inputs of any other module downstream in the pipeline. Moreover, the output of any module can be mapped from the pipeline to a sink as well as subsequent modules. This makes it possible to create modules with more general implementations that are completely decoupled from other modules except for the data types of their inputs and outputs. And, in this model, a pipeline represents a single arbitrarily complex data analysis unit composed of simple modules.

[0068] Second, data mapping into, inside, and outside the pipeline is not restricted by data type: pipeline inputs can be of any available data type, and pipeline internal processing and output can also be of any available data type - as long as the modules that input the data are implemented to do so.

[0069] Third, incoming data can be mapped to more than one pipeline at a time, with each pipeline performing a different type of processing - perhaps using different data types from different functions of the digital processor - and outgoing data can be mapped to multiple outputs for further processing. In other words, multiple process inputs can be mapped to multiple pipelines, and pipeline outputs can be mapped to multiple process outputs - all simultaneously and without interfering with each other.

[0070] Various embodiments described herein may include a "pipelined data processor" which may include:

[0071] 1 to N "source modules" that take one or more data types using any method required and use any input data type to generate the data.

[0072] Modules of that type "pump" that data through any pipeline;

[0073] 1 to N "pipelines", each pipeline comprising 1 to N "pipeline analysis modules" that input one or more data types and output one or more data types, using mapping rules that allow bypassing of subsequent or previous modules; and

[0074] 1 to N "receive modules" that map to the data type or data types output by the pipeline and forward that data using whatever method is desired.

[0075] The pipeline data processor can provide a basic framework for performing continuous data processing via arbitrary modules, where the modules implement a simple interface but can perform their functions in any way that is suitable for the data and digital processor they operate on. Thus, the source module can obtain raw data from a CAN (Controller Area Network) bus, a file or queue, a network connection, or any other function of the digital processor. Similarly, the receiving module can send processed data in any way, and the pipeline analysis module can use any function of the digital processor as needed to perform its functions.

[0076] Some embodiments described herein can be characterized by easy creation of pipelines and pipeline data processors composed of many small and adaptable modules. Various embodiments described herein can provide a conceptual framework for understanding how modules operate and how to combine into data processing systems; provide a runtime framework to host pipeline data processors composed of modules to implement these data processing systems; and provide cross-platform libraries that can be used to create cross-platform implementations for selected system function module developers.

[0077] Various embodiments may host a pipeline data processor in a sandbox and provide it with a cross-platform library for accessing basic digital processor functions. Resource usage may be restricted via the sandbox and / or cross-platform modules via the library. Various embodiments may provide constraints and encourage module reusability while also providing ways to perform operations outside of these restrictions when the use case requires it. Module developers may implement the framework and cross-platform library, and the same code will run in a variety of hardware and / or software environments.

[0078] Some embodiments may implement pipelined data processors and / or sandboxes in a manner appropriate to the digital processor and its functionality, meaning that multithreading and process control (if provided) may be utilized (if not, then implemented without these features). Resource requirements may be reduced on low resource systems and / or data processing may be throttled if required.

[0079] Since individual modules may be simple to implement and mapping rules may be very easy to implement, the resource usage of a pipelined data processor consisting of pipelines and modules may be comparable to the same use case implemented as a monolithic system that is difficult to maintain.

[0080] Finally, on large interconnected systems with multiple digital processors, source modules can provide raw data (and may also perform minimal processing to reduce network usage on some devices), and then send partially processed data to one or more other devices in the system for further processing; distributing the processing load like some "map-reduce" implementations, but using a framework designed to provide significantly more control over how and where processing occurs (e.g., on multiple devices on the same edge client, multiple collaborating edge clients, or a mix of edge clients and cloud servers).

[0081] Figure 1 A system 100 is schematically shown according to various embodiments, the system comprising a pipelined data processor host 10 (e.g., a sandbox) for providing continuous data processing. The pipelined data processor host 10 serves as a host for one or more pipelined data processors 15 (e.g., pipelined processors), providing access to the underlying operating system and hardware drivers 5 via a cross-platform API 12 (e.g., a portable API (application programming interface)). The pipelined data processor host 10 can control the pipelined data processor runtime operation and restrict its access to system resources (including memory and physical processor resources).

[0082] If a sink (e.g., sinks A and B), source (e.g., source A and B), or pipeline analysis module (e.g., module A-module C) requires access to system resources not mediated by the pipeline data processor host 10, any external library 25-27 can be compiled into the pipeline data processor 15 to provide these functions.

[0083] Modules written using only the cross-platform API 12 can run on a variety of platforms (e.g., any system with sufficient resources for these modules). In various embodiments, the cross-platform API 12 may include a signal API for capturing system data (e.g., CAN bus signals), a message bus API for sending and receiving data over an internal client network, or other host and system APIs to support pipeline data processors 15 and modules (which may include runtime logging or profiling capabilities).

[0084] In various embodiments, a source module (e.g., source A or source B in this example) may use a mapping function to map incoming data of a continuous data stream to different reducers selected from different pipeline analysis modules in the pipeline analysis module. Figure 8 , source A is mapped to the initial module of the first pipeline (e.g., including module A-module D) and the initial module of the second pipeline (e.g., including modules E, F, C, and D), source B is mapped to the initial module of the second pipeline and the initial module of the third pipeline (e.g., including modules E, G, H, and D), and source C is mapped to different modules of the third pipeline. One or more of these reducers can use a mapping function to map the output of the reducer to different reducers / receivers selected from the pipeline analysis module or receiver (e.g., the output of module A of the first pipeline is mapped to modules A and C, module E of the second pipeline is mapped to module F, and module E of the third pipeline is mapped to module H). The mapping function can be implemented by generating code for the mapping, where the functionality of the runtime code is different from some pure mapping implementations because it is specific to the mapping input used to generate the code. The mapping function is considered a general data-driven implementation; however, they can be pre-optimized by directly converting data into specific code via a code generator.

[0085] In various embodiments, the mapping function can be a data-driven general implementation driven by a mapping description (e.g., pipeline description language code), or can be optimized at runtime by generating mapping-specific source code from the mapping description. In various embodiments, the mapping can be performed by data type and / or module which outputs the data, rather than by key as in some other mapping methods.

[0086] Reference again Figure 1 , the system 100 may be implemented using one or more hardware processors. In various embodiments, the one or more hardware processors may be part of a single device or distributed across interconnected devices that communicate with each other through external interfaces.

[0087] In various embodiments, the one or more hardware processors may include a general purpose integrated circuit (eg, a general purpose CPU) or an application specific integrated circuit (ASIC), or a combination thereof.

[0088] In one embodiment, the system 100 can be used for vehicle edge data processing. The system 100 can pre-process data generated by vehicle sensors on the "edge" before the data is sent to the cloud via a communication network. In such an example, the source module can provide data originating from the vehicle (e.g., vehicle sensor data in a raw or pre-processed state), and the receiving module can provide pipelined data to the cloud. Pipeline processing can transform vehicle sensor data to reduce transmission costs, avoid data throttling, protect data privacy, optimize distributed data analysis involving the cloud, etc.

[0089] A vehicle edge data processing implementation may include one or more pipeline data processors and data agents (similar to Figure 4 and Figure 5 ). The data proxy can run on the same device as one or more pipeline data processors, or it can reside on a separate device. The data proxy can cache pipeline processed data (from one or more first devices) locally until an appropriate Internet network connection is available. Availability can be determined using rules for expected opportunities or scenarios, including caching until any network is available, caching until a low-cost or higher bandwidth network is available, sending high-value or low-volume data over a lower bandwidth or more expensive network and caching other data until a low-cost or higher bandwidth network is available, etc., or a combination thereof. When availability is detected, the data proxy can send the cached data to the server for further processing, after which the data proxy can clear the cache.

[0090] In the case of vehicle edge data processing, the pipeline data processor 15 can be implemented using embedded vehicle hardware devices, such as ECUs (electronic control units). Embedded vehicle hardware devices can include single-purpose I / O hardware, which can utilize hardware processors including general-purpose CPUs and ASICs.

[0091] System 100 can be used in a variety of applications and in the field of vehicle data processing or other fields. In some embodiments, pipeline processing can perform dynamic distributed processing on a server cluster, where extremely large amounts of data are processed in multiple ways through multiple steps. In some embodiments, pipeline processing can perform advanced media (e.g., video, audio, 3D) processing distributed across multiple cores of a CPU or multiple devices to achieve better throughput. In some embodiments, pipeline processing can perform message-based operating system processing.

[0092] Figure 2 A system 200 is schematically shown for providing continuous data processing using devices AD interconnected by a client internal network 219 according to various embodiments. To provide low-cost parallel processing, pipeline data processors 215-217 can be hosted by separate devices AB, respectively, which can communicate with each other through the network 219 using their external interfaces. Some corresponding devices may include 1 to N source modules (obtaining data from any data producer described herein), and one to N receiving modules that send the data elsewhere for further processing (we use the term "N" here and throughout this disclosure to indicate that any value of the number of source modules can be the same or different from the number of receiving modules). In this embodiment, a receiver on device A can publish data subscribed by a source on device B. A receiver on device B can publish data subscribed by a source on device C. A receiver on device C can publish data subscribed by an external process on device D.

[0093] The pipeline data processors 215-217 can communicate with each other to implement distributed data processing on the client, or to combine data from separate devices for edge computing applications. The pipeline data processors 215-217 can also send data to a local external process or a process on another device D. In the example shown, the message bus subscriber of device D can be associated with any upload process described herein to cache data and upload it to a cloud server.

[0094] Communication through the network 219 can be performed using a message bus based on publish / subscribe semantics. The message bus can be specific to the client, its internal network, and the devices contained therein. Available message bus protocols include MQTT (MQ Telemetry Transport) and SOME / IP (Extensible Service-Oriented Middleware / Internet Protocol) or other protocols with similar semantics. In order to implement message bus data exchange, there can be source and receiving modules that are configured to publish or subscribe to selected data messages using appropriate message bus protocols.

[0095] In this example, pipeline data processors 215-217 are implemented on different hardware processors that are distributed on different devices (e.g., device A-device C) that are interconnected using external connectivity (client-internal network or some other message bus). In other examples, one or more pipeline data processors may be implemented on a hardware processor of a single device. For example, different pipeline analysis modules (e.g., reducers) of the same pipeline data processor may be (e.g., respectively) implemented on different cores. In another example, a pipeline analysis module of one pipeline data processor may be implemented on one core, while a pipeline analysis module of another pipeline data processor may be implemented on another core.

[0096] Figure 3 Schematically illustrates a package 300 that can be deployed on one or more devices to provide continuous data processing on the device according to various embodiments. The package 300 can specify 1 to N pipeline data processors for a specific edge data client, depending on the brand and model, which together constitute a single edge data processing application or campaign. The package specification can include everything required to build all binary assets for the pipeline data processor on the client, as well as related metadata and data management configuration.

[0097] In various embodiments, package 300 includes one or more pipeline data processors in a package description language (PDL) or some other description form, as well as build and deployment information. Package 300 can be a PDL package that a build system can consume to output all binaries and other assets required for installation on a client.

[0098] Each pipeline data processor can operate independently and in some cases can be directed to a separate computing device on the client (e.g., devices that communicate with each other through their external interfaces). However, data can be forwarded from a message bus sink module on one pipeline data processor to a message bus source module on another pipeline data processor, thereby allowing distributed data processing on the client.

[0099] Figure 4 Schematically illustrates a package 400 that can be deployed on a single device to provide continuous data processing on a single device according to various embodiments. When the package 400 is targeted at a single device client, binary assets of a single pipelined data processor host application and pipelined data processor implemented for the device can be created and installed.

[0100] The data proxy application may be pre-installed or installed with the pipeline data processor host / pipeline data processor. The data proxy may be responsible for caching data until a connection to the cloud is possible. In various embodiments, a single system-wide data proxy may also provide message proxy functionality if required by the message bus (MBUS) protocol. The data proxy may collect output data specified in a packet from a receiving module in the pipeline data processor and securely send it to a cloud server for retention and further processing.

[0101] Figure 5 Schematically illustrates a package 500 that can be deployed on an interconnect device to provide continuous data processing on the interconnect device according to various embodiments. When the package 500 targets a multi-device client, a pipeline data processor host application and pipeline data processor binary assets for each target device in the package 500 are created and installed.

[0102] A data proxy application may be required on a device with an internet connection, but may be pre-installed or installed with the pipeline data processor host / pipeline data processor. The data proxy may collect output data specified in a packet from the receiving modules in the pipeline data processor and securely send it to a cloud server for retention and further processing.

[0103] Figure 6 A forward-only pipeline 600 is schematically shown that provides sequential data processing according to various embodiments. In a simple pipeline (not shown), data can be provided via a source, processed by each module in the pipeline, and then exit the pipeline at a sink. This can lead to a rigid implementation where modules can only be combined if the module input data is output by the previous module in the pipeline; limiting code reuse and composability or limiting the types of data that modules can operate on.

[0104] In an unrestricted, out-of-order module group (not shown), data may be provided by a source, may be processed by each module in the subgroup along multiple paths (unlike a simple pipeline which may have only one path), and then exit the group at a sink. The multiple paths of an unrestricted, out-of-order module group may include multiple inputs and outputs.

[0105] While an unrestricted, unordered group of modules may be more flexible than a simple pipeline, it may be a collection of modules connected arbitrarily together (with a single entry and exit point), which may require a monolithic implementation. This may limit code reuse and composability, or restrict the types of data that the modules can operate on. Moreover, such a group of modules is an open network graph (rather than a pipeline). In an open network graph, modules serve as nodes (e.g., vertices) and data paths are connections between them (e.g., edges), which may lead to extreme and arbitrary complexity and require a monolithic implementation.

[0106] In a forward-only pipeline, data enters via a source module and may be processed by each pipeline analysis module in the pipeline along multiple paths. These multiple paths are limited to subsequent modules or receiving modules in the pipeline (e.g., no backward chaining) and may then exit the pipeline at a receiver.

[0107] This style of pipelining provides greater flexibility than simple pipelining while avoiding the complexity of an unrestricted, unordered group of modules. Modules can be combined in any way that suits their expected data inputs and outputs, but the inputs must be output by another module earlier in the pipeline, and the outputs must be consumed by another module later in the pipeline.

[0108] In various embodiments, the pipeline data flow can be controlled by a pipeline data processor, which can start the flow for each source by calling a heartbeat function. In this example, the source can use the signal API to obtain signal data, and then pass the data to pipeline analysis module A, which in turn passes the data to pipeline analysis module B and pipeline analysis module C.

[0109] Pipeline analysis module B can pass its output directly to the receiving module, which can use the message bus API to send the data out as a message. Pipeline analysis module C can send its output to pipeline analysis module D, and then pipeline analysis module D can send its output to the receiver to send as a message.

[0110] The entire processing cascade can start from the heartbeat function of the source and occur within a single execution thread. The pipeline data processor can drive data through all pipelines in a single thread, which can reduce the complexity of the implementation. The modules of the pipeline data processor can themselves independently run separate threads and perform their own thread synchronization (to execute in the same thread as the pipeline data processor).

[0111] Figure 7 A single-pipeline data processor 700 providing continuous data processing according to various embodiments is schematically illustrated. In a single-pipeline data processor (e.g., a single-pipeline processor), data may be provided by one to N sources, processed by a forward-only pipeline (having multiple paths), and then exit at one to N sinks.

[0112] Figure 8A multi-pipeline data processor 800 providing sequential data processing according to various embodiments is schematically illustrated. In a multi-pipeline data processor (e.g., a multi-pipeline processor), data may be provided by one to N sources, processed by one or more forward-only pipelines (each pipeline having multiple paths), and then exit at one to N receiving modules.

[0113] Multi-pipeline data processors combine the limited flexibility of forward-only pipelines with the ability to share data sources and sinks between them. Although highly complex processors can be created, the conceptual complexity is advantageously limited because each pipeline can operate as a separate processing unit.

[0114] The multi-pipeline data processor of various embodiments described herein may correspond to a PDL model of a pipeline, where:

[0115] The pipeline analysis module is a computational entity that exists within the pipeline;

[0116] The pipeline analysis module is opaque because the pipeline is the smallest entity abstraction of computing;

[0117] Data enters the pipeline through pipeline inputs and exits through pipeline outputs;

[0118] Pipelines can be discrete entities that can be added or removed from a processor without affecting the operation of any other pipelines; and

[0119] The inlet-to-outlet data flow can follow the following rules: 1) A pipeline can be represented by a directed graph, where pipeline inputs, analysis modules, and pipeline outputs represent nodes, and the flow of data elements from the outlet to the inlet represents edges; and 2) A pipeline is valid if and only if the graph has no cycles, all analysis modules and pipeline outputs have at least one edge, and all terminal nodes are pipeline outputs.

[0120] The data processing modules described herein can be combined to form a single computing unit (e.g., a single edge computing unit). Each data processing module may include independent code that can be embedded in software for independent purposes. The independent code can receive data, output data, and may have an API that the independent code of other data processing modules (for other independent purposes) can reference to consume or pass data to.

[0121] Most of the devices discussed above include hardware and associated software. For example, a typical continuous data processing system may include one or more hardware processors and software executable on these hardware processors to perform the operations. We use the commonly understood meaning of the term "software" here to refer to programs or routines (subroutines, objects, plug-ins, etc.) and data that can be used by a machine or hardware processor. As is well known, a computer program typically includes instructions stored in a machine-readable or computer-readable storage medium. Some embodiments of the present invention may include executable programs or instructions stored in a machine-readable or computer-readable storage medium (e.g., digital memory). We do not imply that a "computer" in the traditional sense is required in any particular embodiment. For example, various processors (embedded or otherwise) can be used in devices such as the components described herein.

[0122] Memories for storing software are also well known. In some embodiments, the memory associated with a given processor may be stored in the same physical device as the processor ("on-board" memory); for example, RAM or FLASH memory provided in an integrated circuit microprocessor, etc. In other examples, the memory includes a separate device, such as an external disk drive, a storage array, or a portable FLASH keychain. In this case, the memory is "associated" with the digital processor when the two are operably coupled together or communicate with each other, such as through an I / O port, a network connection, etc., so that the processor can read files stored on the memory. The associated memory may be "read-only" (ROM) by design or "read-only" according to permission settings, or it may not be. Other examples include, but are not limited to, WORM, EPROM, EEPROM, FLASH, etc. These technologies are typically implemented in solid-state semiconductor devices. Other memories may include moving parts, such as traditional rotating disk drives. All of these memories are "machine-readable" or "computer-readable" and can be used to store executable instructions for implementing the functions described herein.

[0123] "Software Product" means a storage device having stored therein a series of executable instructions in machine-readable form so that an appropriate machine or processor, with appropriate access to the software product, can execute the instructions to perform the process implemented by the instructions. Software products are sometimes used to distribute software. Any type of machine-readable storage (including, but not limited to, the above-mentioned storage) may be used to make a software product. Nevertheless, it is well known that software may be distributed via electronic transmission ("download"), in which case there will typically be a corresponding software product at the sending end or the receiving end or both of the transmission.

[0124] The principles of the present invention have been described and illustrated in the preferred embodiments of the present invention. Obviously, the present invention can be modified in arrangement and details without departing from these principles. We require that all modifications and variations are within the spirit and scope of the appended claims.

Claims

1. A device comprising: at least one hardware processor; as well as A pipeline data processor implemented on the at least one hardware processor, the pipeline data processor comprising: at least one source module for providing at least one continuous data stream to one or more processing pipelines; and at least one receiving module for inputting data from the one or more processing pipelines; Wherein, the pipeline data processor includes: a plurality of different paths extending through a plurality of pipeline analysis modules; Wherein, the input path is forward-only, requiring the input of a pipeline analysis module of the processing pipeline to be output by another pipeline analysis module earlier in the processing pipeline or the at least one source module.

2. The device according to claim 1, wherein: The one or more processing pipelines include: a plurality of processing pipelines, wherein at least one source includes: one or more first sources for outputting data to a first processing pipeline among the plurality of processing pipelines; and one or more second sources for outputting data to a second processing pipeline among the plurality of processing pipelines.

3. The device according to claim 1, wherein: The one or more first sources also output data to the second processing pipeline.

4. The device according to claim 3, wherein: The one or more first sources and the one or more second sources output data to a same pipeline analysis module of the second processing pipeline.

5. The device according to claim 3, wherein: The one or more first sources and the one or more second sources output data to different pipeline analysis modules of the second processing pipeline.

6. The device according to claim 1, wherein: The one or more processing pipelines include a single processing pipeline, and a first path of the plurality of different paths extends through a combination of the pipeline analysis modules, and a second path of the plurality of different paths extends through a subset of the pipeline analysis modules in the combination.

7. The device according to claim 1, wherein: Each of the one or more processing pipelines includes: a separate processing unit.

8. The device according to claim 7, wherein: The pipelined data processor operates on different cores of the at least one hardware processor, and wherein the separate processing units correspond to different independent ones of the different cores.

9. The device according to claim 7, wherein: The at least one hardware processor includes: hardware processors distributed on different devices interconnected using external connectivity.

10. The device according to claim 1, wherein: A source module of the at least one source module uses a mapping function to map incoming data of the at least one continuous data stream to different reducers, the different reducers being selected from different ones of the pipeline analysis modules, and At least one of the reducers uses a mapping function to map the output of the at least one reducer to a different reducer / receiver, wherein the different reducer / receiver is selected from the pipeline analysis module or at least one receiver.

11. The apparatus of claim 1 , further comprising a processing host implemented on the at least one hardware processor, the processing host being configured to control runtime operation of the pipeline data processor to fully or partially regulate access to system resources by the pipeline data processor.

12. The device according to claim 11, wherein The at least one sink, the pipeline analysis module, or the at least one source directly accesses the system resources using one or more libraries.

13. The device according to claim 11, wherein: The processor host uses a portable API (Application Programming Interface) to fully or partially regulate the access.

14. The device according to claim 13, wherein: The portable API includes: a signal API for capturing CAN (Controller Area Network) bus signals or other system data; or a message bus API for sending and receiving data through an internal client network.

15. The device according to claim 13, wherein: The portable API includes runtime logging or profiling functionality.

16. An apparatus comprising: at least one hardware processor; as well as a pipeline data processor implemented on the at least one hardware processor, the pipeline data processor comprising: at least one source module providing at least one continuous data stream; a single forward-only pipeline including a sequence of pipeline analysis modules, or a plurality of forward-only pipelines including a plurality of sequences of pipeline analysis modules; and at least one receiving module; wherein a source module in the at least one source module uses a mapping function to map incoming data of the at least one continuous data stream to different reducers, the different reducers are selected from different pipeline analysis modules in the pipeline analysis modules, and different analysis modules in the analysis modules are selected from the pipeline analysis module sequence or the plurality of pipeline analysis module sequences, and At least one of the reducers uses a mapping function to map the output of the at least one reducer to a different reducer / receiver, wherein the different reducer / receiver is selected from the pipeline analysis module sequence, the multiple pipeline analysis module sequences or the at least one receiver.

17. The device according to claim 16, wherein: The pipeline data processor operates on different cores of the at least one hardware processor.

18. The device according to claim 16, wherein: The at least one hardware processor includes: hardware processors distributed on different devices interconnected using external connectivity.

19. The device according to claim 18, wherein: Different ones of the reducers are operated by different ones of the hardware processors.

20. The device according to claim 16, wherein: The at least one data source obtains data from: a CAN (Controller Area Network) bus, a file or queue, a network connection, or other resources of the at least one hardware processor.

Images