Disclosure of Invention
In view of the above drawbacks of the prior art, the present invention provides a method for acquiring a cloud data acquisition system architecture of a vehicle, so as to solve the problems of reduced life cycle, increased maintenance cost of the software and data acquisition only for a specific protocol.
The invention provides a method for acquiring a vehicle cloud data acquisition system architecture, which comprises the following steps:
Acquiring information of service use cases of a plurality of vehicle cloud data acquisition system architectures through analysis of service requirements of the vehicle cloud data acquisition system architectures;
Splitting the information of the service cases to obtain the information of a domain model of the vehicle cloud data acquisition system architecture and the information of a plurality of service concepts in the domain model;
step splitting is carried out on the functions to be realized by the business concepts, and the domain service information of the vehicle cloud data acquisition system architecture is obtained;
Arranging the information of the domain service, obtaining the information of interface protocol interacted with ports of a plurality of plug-in adapters, and
And according to the information of the interface protocol, the plug-in adapters interact with the vehicle cloud data acquisition system.
In an embodiment of the present invention, the obtaining information of service cases of the plurality of vehicle cloud data acquisition system architectures includes the following steps:
Acquiring boundary information of the vehicle cloud data acquisition system through analysis of service requirements of the vehicle cloud data acquisition system, and
And obtaining the information of a plurality of service cases by dividing the boundary of the vehicle cloud data acquisition system.
In an embodiment of the present invention, the obtaining the information of the domain model of the vehicle cloud data acquisition system architecture includes the following steps:
the information of key problems in the service cases is obtained through splitting the service cases;
and extracting information of the key problems in the service use cases to obtain information of the domain model.
In an embodiment of the present invention, the method further includes the following steps:
acquiring new types of vehicle-mounted data;
and acquiring port information of a new plug-in adapter matched with the new type of the vehicle-mounted data.
In an embodiment of the present invention, the method further includes the following steps:
arranging the information of the domain service to acquire the information of an interface protocol interacted with a port of the new plug-in adapter;
According to the information of the interface protocol, the new plug-in adapter interacts with the vehicle cloud data acquisition system, and the vehicle cloud data acquisition system acquires and analyzes the new type of vehicle-mounted data.
In one embodiment of the present invention, obtaining information of interface protocols interacting with ports of a plurality of plug-in adapters includes the steps of:
acquiring port information of a warehouse adapter;
Acquiring port information of an acquisition rule adapter;
acquiring port information of the front-end user interface adapter, and
And acquiring port information of the external system adapter.
In one embodiment of the present invention, obtaining information of interface protocols interacting with ports of a plurality of plug-in adapters includes the steps of:
and arranging the information of the domain service according to the port information of the warehouse adapter, the port information of the acquisition rule adapter, the port information of the front-end user interface adapter and the port information of the external system adapter, and acquiring the information of an interface protocol interacted with the port of the warehouse adapter, the port of the acquisition rule adapter, the port of the front-end user interface adapter and the port of the external system adapter.
The invention provides an acquisition device of a vehicle cloud data acquisition system architecture, which comprises:
The system comprises a use case acquisition module, a service case analysis module and a service management module, wherein the use case acquisition module is used for acquiring information of a plurality of service cases of the vehicle cloud data acquisition system architecture through analysis of service requirements of the vehicle cloud data acquisition system architecture;
The domain model acquisition module is used for splitting the information of the plurality of service cases to acquire the information of a domain model of the vehicle cloud data acquisition system architecture and the information of a plurality of service concepts in the domain model;
The domain service acquisition module is used for splitting the steps of the functions to be realized by the business concepts to acquire domain service information of the vehicle cloud data acquisition system architecture;
An interface protocol acquisition module for arranging the information of the domain service, acquiring the information of the interface protocol interacted with the ports of the plug-in adapters, and
And the interaction module is used for interacting the plug-in adapters with the vehicle cloud data acquisition system according to the information of the interface protocol.
The invention provides an electronic device, which comprises:
At least one processor;
And the storage device is used for storing at least one program, and when the at least one program is executed by the at least one processor, the electronic equipment realizes the acquisition method of the vehicle cloud data acquisition system architecture of any one of the above.
The invention provides a computer readable storage medium, which is characterized in that a computer program is stored thereon, and when the computer program is executed by a processor of a computer, the computer is caused to execute the method for acquiring the cloud data acquisition system architecture of the vehicle.
The invention has the beneficial effects that the invention supports the addition of various types of data in the form of the plug-in adapter, thereby achieving the acquisition and analysis of data with different formats. When a new data type is accessed, only one new plug-in adapter is needed to be connected in an interactive way, and the method has the advantages of multiplexing key components and flexible expansion. Meanwhile, on the premise of ensuring the reliable and stable operation of the vehicle cloud data acquisition system, the system can meet various complex and frequent-change business demand scenes, and the service life cycle of the system is prolonged and the maintenance cost of the system is reduced.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application as claimed.
Detailed Description
Further advantages and effects of the present invention will become readily apparent to those skilled in the art from the disclosure herein, by referring to the accompanying drawings and the preferred embodiments. The invention may be practiced or carried out in other embodiments that depart from the specific details, and the details of the present description may be modified or varied from the spirit and scope of the present invention. It should be understood that the preferred embodiments are presented by way of illustration only and not by way of limitation.
It should be noted that the illustrations provided in the following embodiments merely illustrate the basic concept of the present invention by way of illustration, and only the components related to the present invention are shown in the drawings and are not drawn according to the number, shape and size of the components in actual implementation, and the form, number and proportion of the components in actual implementation may be arbitrarily changed, and the layout of the components may be more complicated.
In the following description, numerous details are set forth in order to provide a more thorough explanation of embodiments of the present invention, it will be apparent, however, to one skilled in the art that embodiments of the present invention may be practiced without these specific details, in other embodiments, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the embodiments of the present invention.
It should be noted first that the software architecture (software architecture) is a series of related abstract patterns that are used to guide the design of various aspects of a large software system. The software architecture is a sketch of a system, and objects described by the software architecture are abstract components that directly constitute the system. The connection between the various components describes the communication between the components explicitly and relatively carefully. In the implementation phase, these abstract components are refined into actual components, such as concrete classes or objects. In the object-oriented field, connections between components are typically implemented with interfaces. When a system with complex business needs to be built, not only a robust technical architecture needs to be built from the technical perspective, but also a business architecture needs to be built as long as the business requirements that the system can meet needs to be guaranteed. The DDD (Domain DRIVEN DESIGN, domain driver design) integrates the technical architecture and the service architecture, which can embody the system service and guide the development of technical codes.
The field driving design can split the complex problems, and split the association of all subsystems, how the subsystems operate and how the subsystems are connected with each other, so that the principle that a large complex system should follow in landing is solved. The domain driving design is an idea of driving system design by a domain model, wherein the domain model is an abstraction of a service model, the domain model carries attributes and specific behaviors of a service and is a method for expressing the service, and the domain model is a class with attributes, and the attributes comprise setting attributes and acquiring attributes. The behavior operation of the service is also in a model class, namely service logic operation, and is also called a data transmission object. The domain model comprises three types of entities, value objects and services. The hierarchical structure of the domain driver design comprises a user interface layer, an application layer, a domain layer and a basic implementation layer.
Fig. 1 is an application environment schematic diagram of an acquisition method of a vehicle cloud data acquisition system architecture according to an exemplary embodiment of the present application. As shown in fig. 1, in some embodiments, according to the service requirements of the vehicle cloud data acquisition system architecture, the relation between the service requirements, and the steps of implementing the functions required by the service requirements, the vehicle cloud data acquisition system architecture acquisition module 110 acquires the vehicle cloud data acquisition system architecture, the technician 120 performs the technical architecture design according to the vehicle cloud data acquisition system architecture, and completes the vehicle cloud data acquisition system, that is, the vehicle cloud data acquisition application 130, and the three-party service 140 includes a data storage, an acquisition rule, a user interface, and a three-party data analysis system, and is connected with the vehicle cloud data acquisition application 130 through the interface of the vehicle cloud data acquisition application 130, and transmits data to the vehicle cloud data acquisition application 130 or invokes data in the vehicle cloud data acquisition application 130. The embodiment of the present application does not limit the specific function of the vehicle cloud data collection system architecture obtaining module 110, and the vehicle cloud data collection application 130 shown in fig. 1 may be, for example, an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server that provides cloud services, a cloud database, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs (Content Delivery Network, content distribution networks), and basic cloud computing services such as big data and artificial intelligent platforms. The data transmitted between the vehicle cloud data collection application 130 and the three-party service 140 may be operated through wireless networks such as 3G (third generation mobile information technology), 4G (fourth generation mobile information technology), 5G (fifth generation mobile information technology), etc., which is not limited in this embodiment of the present application, and may be set according to actual requirements.
In some embodiments, the existing data acquisition software designed through the software architecture is often designed only for a specific protocol, so that the data acquisition can only identify parameter data in a specific protocol format, and when a new data specification needs to be acquired and analyzed, key components cannot be directly multiplexed and flexibly expanded. In order to solve the problems, the embodiments of the present application respectively provide a method, a device, equipment and a medium for acquiring a vehicle cloud data acquisition system architecture, and the embodiments will be described in detail below.
Referring to fig. 2, fig. 2 is a flowchart illustrating an acquisition method of a vehicle cloud data acquisition system architecture according to an exemplary embodiment of the application. In some embodiments, the method may be applied to the implementation environment shown in fig. 1, and specifically executed by the acquisition module 110 of the vehicle cloud data acquisition system architecture in the implementation environment. It should be understood that the method may be adapted to other exemplary implementation environments and be specifically executed by devices in other implementation environments, and the implementation environments to which the method is adapted are not limited by the present embodiment.
For example, an SDK (Software Development Kit, a software development kit, which is a development kit set for establishing application software for a specific software package, a software framework, an operating system, etc.) may be installed in the acquisition module 110 of the vehicle cloud data acquisition system architecture to which the method for acquiring the vehicle cloud data acquisition system architecture disclosed in the present embodiment is applicable, and the method disclosed in the present embodiment is specifically implemented as one or more functions provided by the SDK externally.
As shown in fig. 2, in an exemplary embodiment, the method for acquiring the vehicle cloud data acquisition system architecture at least includes steps S210 to S250, which are described in detail as follows:
step S210, obtaining information of service use cases of a plurality of vehicle cloud data acquisition systems through analysis of service requirements of the vehicle cloud data acquisition systems.
Firstly, the business requirements of the vehicle cloud data acquisition system architecture are analyzed, and then the boundaries of the vehicle cloud data acquisition system are divided, so that business use cases are extracted. The business use case expresses the requirement of a user on the vehicle cloud data acquisition system, and defines the boundary of the vehicle cloud data acquisition system and the scene of external roles and system interaction of the vehicle cloud data acquisition system. The main service cases in the system comprise service cases for collecting data of various specifications uploaded by vehicles, service cases for identifying vehicle-mounted data, service cases for analyzing and transmitting processed data, and the like.
The boundary of the vehicle cloud data acquisition system is a limiting context, and an application range of the model is defined.
Step S220, splitting information of a plurality of service cases to obtain information of a domain model of a vehicle cloud data acquisition system architecture and information of a plurality of service concepts in the domain model.
By splitting the service use cases, key problems in the service use cases are acquired, and the field concept of the vehicle cloud data acquisition system is extracted from the key problems. And then obtaining a conceptual model according to the domain concepts, and converting the conceptual model into a domain model. The obtaining mode for realizing the field model comprises a brain storm and an experiment, so that the service concept used in the vehicle cloud data acquisition system is abstracted. The business concepts comprise structured data concepts, semi-structured data concepts and unstructured data concepts.
The domain model is an abstraction of a domain with a certain boundary, and the domain model only reflects the business and is irrelevant to the task technology implementation, and reflects the essence of the business requirement of users in the domain.
Step S230, splitting the functions to be realized by the business concepts to obtain the domain service information of the vehicle cloud data acquisition system architecture.
The method comprises the steps of splitting the functions to be realized by the service requirements of the vehicle cloud data acquisition system architecture represented by the service concept, and obtaining a plurality of steps included in the functions for realizing the service requirements. And then refining and extracting a plurality of key steps from the plurality of steps, and corresponding the key steps to a vehicle cloud data acquisition system, wherein the plurality of key steps for realizing the business requirements are refined into the capabilities of the domain service. And the capability has atomicity, so that the capability responsibility in the domain service can be ensured to be single and not divisible, and a plurality of domain services can be called to realize the task specific to a certain domain.
Among these, domain services have three features, the first is to emphasize a stateless operation, where state should be maintained in an entity, and domain services handling is a stateless logical process. The second feature is to implement a task in a certain domain, what is done is within the domain boundaries. The domain service is not an application service, which is a client of the domain service, such as an API (Application Programming Interface, application program interface) aggregation service, and the application service does nothing within the domain. A third feature is to consider modeling of aggregate or value objects first, and use domain services if an operation is not fit on an aggregate or value object. The domain service refers to the abstraction of the functions which can be completed by the vehicle cloud data acquisition system, namely the domain service is the aggregate of all core business functions which can be completed by the system, and the domain service comprises the functions of intelligent identification, transmission, monitoring, preprocessing, management and the like of data.
Step S240, arranging the domain service information to acquire interface protocol information interacted with ports of a plurality of plug-in adapters.
The capability provided by the domain service has atomicity, so that the adaptation to the business requirement of the vehicle cloud data acquisition system architecture is required to be realized through arrangement and combination of the domain service. The vehicle cloud data acquisition system architecture comprises a field layer, an application program layer, namely an application layer and a plug-in adaptation layer. The domain layer is the extraction of a core business object and a core business logic of the vehicle cloud data acquisition system, and comprises a domain object and a domain service. The domain layer is only responsible for expressing business concepts, business state information and business rules. The domain object includes a domain model. The application layer has responsibilities for the organization and orchestration of domain objects and domain services. Wherein the plug-in adapter layer comprises a plurality of plug-in adapters. Because the application layer and the field layer do not care about which technology is specifically used, only input object data needs to be acquired, and output object data information required by interfaces of all plug-in adapters is built through aggregation. Therefore, after obtaining port information of the plurality of plug-in adapters, such as port information of a warehouse adapter, port information of an acquisition rule adapter, port information of a front-end user interface adapter and port information of an external system adapter, an interface protocol for interacting with the plurality of plug-in adapters is established at an application layer by arranging domain services, and data specifications of input items and output items are specified. The advantage of doing so is that each module is decoupled, so that single responsibility is realized, and the collection and uploading of various data rules and the interaction function with different systems can be supported. When the data to be analyzed is newly added or changed, only the plug-in adapter needs to be flexibly expanded, and the method has the characteristics of multiplexing key components and flexible expansion.
The plug-in adaptation layer comprises a storage adapter, an acquisition rule adapter, a front end UI (User Interface) adapter and an external system adapter. The warehouse adapter is mainly interacted with a data storage, wherein the data storage comprises a relational database, a non-relational database, a file and the like. The acquisition rule adapter adapts data formats with different specifications according to the unified interaction interface specification provided by the application layer, and interacts the adapted data with the application layer, so that the purposes that a plurality of different data formats can be recognized by the system and subsequent business processing is achieved. And the front-end UI adapter and the acquisition rule adapter are hierarchically and at the same level, display and interaction of different data types are performed, and data are displayed on a front-end UI interface or uploaded to a vehicle cloud data acquisition system. The external system adapter mainly realizes data interaction, function call and the like between the external system adapter and other systems.
Step S250, according to the information of the interface protocol, the plug-in adapters interact with the vehicle cloud data acquisition system.
The vehicle cloud data acquisition system is arranged on the application program layer, and a plurality of plug-in adapters are used for converting input and output items of other systems or three-party services into data formats which can be identified by the application program layer and the field layer, and the data formats are converted through the plug-in adapters according to interface specifications formulated by the application program layer, so that the acquired data in different formats can be identified and processed by the vehicle cloud data acquisition system. The three-party service mainly refers to services of an application program layer and a domain layer of a core business logic processing part in the cloud data acquisition system of the vehicle, and mainly comprises data storage, data acquisition rules, a UI interface and a three-party system. Thus, the most stable parts of the system are the domain layer and the application layer when processing data. This portion, which is the most core portion after the software design is completed, may be made with little or no modification. Because of the existence of the interface protocol with internal interaction, the change is mainly in the plug-in adapter layer, and the layer mainly has the role of adapting the externally changed data to the data conforming to the internal interface standard, so that when each new data needs to be collected, the data to be collected is only converted into the data which can be identified by the internal interface protocol in the form of a plug-in. At this time, the data stream flows from the plug-in adapter layer to the application layer, and is subjected to business processing by the domain service. The plug-in adapter interacts with the vehicle cloud data acquisition system through the interface protocol, the method is not only limited to acquiring data in various different formats generated by a plurality of three-party services, but also can realize interaction through adapting in a similar plug-in adapter mode through UI interfaces, data storage and data analysis of the three-party data analysis system.
Fig. 3 is a flowchart of a method for acquiring a service instance according to an exemplary embodiment of the present application. As shown in fig. 3, in an exemplary embodiment, the method for obtaining a service instance at least includes steps S310 to S330, which are described in detail as follows:
Step S310, obtaining information of service requirements of a vehicle cloud data acquisition system.
Step S320, the boundary information of the vehicle cloud data acquisition system is obtained by analyzing the information of the service requirements.
The boundary of the vehicle cloud data acquisition system is a limiting context, and the application range of the model is defined. .
Step S330, the boundary of the vehicle cloud data acquisition system is divided, so that information of a plurality of service cases is obtained.
The main service cases in the cloud data acquisition system of the vehicle comprise service cases for acquiring data of various specifications uploaded by the vehicle, service cases for identifying vehicle-mounted data, service cases for analyzing and transmitting processed data, and the like.
Fig. 4 is a flowchart of a method for acquiring a service concept according to an exemplary embodiment of the present application. As shown in fig. 4, in an exemplary embodiment, the method for obtaining the service concept at least includes steps S410 to S420, which are described in detail as follows:
In step S410, the information of the key problem in the service case is obtained by splitting the service cases.
Step S420, the information of the domain model is obtained through extracting the information of the key problems in the service use cases.
The method comprises the steps of obtaining key problems in the service case through splitting the service case, and extracting the domain concept of the vehicle cloud data acquisition system from the key problems. And then obtaining a conceptual model according to the domain concepts, and converting the conceptual model into a domain model. The domain model is an abstraction of a domain with a certain boundary, and the domain model only reflects the business and is irrelevant to the task technology implementation, and reflects the essence of the business requirement of users in the domain.
Fig. 5 is a flowchart of a method for acquiring data after a new type of data is accessed according to an exemplary embodiment of the present application. As shown in fig. 5, in an exemplary embodiment, after the new type of data is accessed, the data acquisition method at least includes steps S510 to S530, which are described in detail as follows:
step S510, acquiring new types of vehicle-mounted data.
An external three-way service such as an automatic navigation system may be used, and the automatic navigation system may generate new types of vehicle-mounted data.
Step S520, obtaining port information of a new plug-in adapter matched with the new type of vehicle-mounted data.
For example, the automatic navigation system may match an automatic navigation adapter, i.e., a new plug-in adapter.
And step S530, arranging the information of the domain service to acquire the information of an interface protocol interacted with the port of the new plug-in adapter.
The capability provided by the domain service has atomicity, so that the adaptation to the business requirement of the vehicle cloud data acquisition system architecture is realized through arrangement and combination of the domain service. And obtains an interface protocol that interacts with the port of the new plug-in adapter.
Step S540, according to the information of the interface protocol, the new plug-in adaptor interacts with the vehicle cloud data acquisition system, and the vehicle cloud data acquisition system acquires and analyzes new types of vehicle-mounted data.
Through an interface protocol interacting with a port of the new plug-in adapter, the new plug-in adapter interacts with the vehicle cloud data acquisition system, the vehicle cloud data acquisition system acquires and analyzes new types of data, and the three-party service can also call vehicle-mounted data in the vehicle cloud data acquisition system.
Fig. 6 is a schematic structural diagram of an acquisition device of a vehicle cloud data acquisition system architecture according to an exemplary embodiment of the present application. The device can be applied to the application environment shown in fig. 1, and is specifically configured in the acquisition module 110 of the vehicle cloud data acquisition system architecture. The apparatus may also be adapted to other exemplary implementation environments and may be specifically configured in other devices, and the present embodiment is not limited to the implementation environments to which the apparatus is adapted.
As shown in fig. 6, the exemplary data security storage device includes:
The system comprises a case acquisition module 610, a domain model acquisition module 620, a domain service acquisition module 630, an interface protocol acquisition module 640 and an interaction module 650, wherein the case acquisition module is used for acquiring information of service cases of a plurality of vehicle cloud data acquisition system architectures through analysis of service requirements of the vehicle cloud data acquisition system architectures, the domain model acquisition module 620 is used for splitting the information of the service cases to acquire information of a domain model of the vehicle cloud data acquisition system architectures and information of a plurality of service concepts in the domain model, the domain service acquisition module 630 is used for splitting functions to be realized by the service concepts to acquire information of domain services of the vehicle cloud data acquisition system architectures, the interface protocol acquisition module 640 is used for arranging the information of the domain services to acquire information of interface protocols interacted with ports of the plug-in adapters, and the interaction module 650 is used for interacting with the vehicle cloud data acquisition systems according to the information of the interface protocols.
Fig. 7 shows a schematic diagram of a computer system suitable for use in implementing an embodiment of the application. It should be noted that, the computer system 700 of the electronic device shown in fig. 7 is only an example, and should not impose any limitation on the functions and the application scope of the embodiments of the present application.
As shown in fig. 7, the computer system 700 includes a central processing unit (Central Processing Unit, CPU) 701 that can perform various appropriate actions and processes, such as performing the methods described in the above embodiments, according to a program stored in a Read-Only Memory (ROM) 702 or a program loaded from a storage portion 708 into a random access Memory (Random Access Memory, RAM) 703. In the RAM 703, various programs and data required for the system operation are also stored. The CPU 701, ROM 702, and RAM 703 are connected to each other through a bus 704. An Input/Output (I/O) interface 705 is also connected to bus 704.
Connected to the I/O interface 705 are an input section 706 including a keyboard, a mouse, and the like, an output section 707 including a Cathode Ray Tube (CRT), a Liquid crystal display (Liquid CRYSTAL DISPLAY, LCD), and the like, and a speaker, and the like, a storage section 708 including a hard disk, and the like, and a communication section 709 including a network interface card such as a LAN (Local Area Network) card, a modem, and the like. The communication section 709 performs communication processing via a network such as the internet. The drive 710 is also connected to the I/O interface 705 as needed. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is installed on the drive 710 as needed, so that a computer program read out therefrom is installed into the storage section 708 as needed.
In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method shown in the flowchart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 709, and/or installed from the removable medium 711. When executed by a Central Processing Unit (CPU) 701, performs the various functions defined in the system of the present application.
It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory, EPROM), a flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer-readable signal medium may comprise a data signal propagated in baseband or as part of a carrier wave, with a computer-readable computer program embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, etc., or any suitable combination of the foregoing.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Where each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units involved in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be provided in a processor. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.
Another aspect of the present application also provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor of a computer, causes the computer to perform the method for acquiring a vehicle cloud data acquisition system architecture as described above. The computer-readable storage medium may be included in the electronic device described in the above embodiment or may exist alone without being incorporated in the electronic device.
Another aspect of the application also provides a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method for acquiring the vehicle cloud data acquisition system architecture provided in the above embodiments.
The above embodiments are merely illustrative of the principles of the present invention and its effectiveness, and are not intended to limit the invention. Modifications and variations may be made to the above-described embodiments by those skilled in the art without departing from the spirit and scope of the invention. It is therefore intended that all equivalent modifications and changes made by those skilled in the art without departing from the spirit and technical spirit of the present invention shall be covered by the appended claims.