CN115756448A

CN115756448A - Method, device, equipment and medium for acquiring vehicle cloud data acquisition system architecture

Info

Publication number: CN115756448A
Application number: CN202211504390.7A
Authority: CN
Inventors: 陈鑫; 谢磊
Original assignee: Chongqing Changan Automobile Co Ltd
Current assignee: Chongqing Changan Automobile Co Ltd
Priority date: 2022-11-28
Filing date: 2022-11-28
Publication date: 2023-03-07

Abstract

The invention provides a method, a device, equipment and a medium for acquiring a vehicle cloud data acquisition system architecture, wherein the method for acquiring the vehicle cloud data acquisition system architecture comprises the following steps: acquiring information of a plurality of service cases through analysis of service requirements; splitting the information of the plurality of service cases to acquire the information of a field model of the vehicle cloud data acquisition system architecture and the information of a plurality of service concepts; step splitting is carried out on the functions of the plurality of business concepts, and information of field services is obtained; arranging the information of the field service, and acquiring the information of interface protocols interacting with the ports of a plurality of plug-in adapters; and according to the information of the interface protocol, a plurality of plug-in adapters interact with the vehicle cloud data acquisition system architecture. By the method for acquiring the vehicle cloud data acquisition system architecture, the expansibility and flexibility of the vehicle cloud data acquisition system architecture are improved.

Description

Method, device, equipment and medium for acquiring vehicle cloud data acquisition system architecture

Technical Field

The application relates to the technical field of software system architectures, in particular to a method, a device, equipment and a medium for acquiring a vehicle cloud data acquisition system architecture.

Background

With the rapid development of automobiles towards networking and intellectualization, a large amount of data generated in the using process of the automobiles is stored in the cloud. The problem is how to acquire information under specific acquisition rules such as key data in the driving process of a vehicle and key information when the vehicle breaks down and upload the information to the cloud so as to facilitate subsequent data analysis and data value mining. Moreover, it is also an important matter to make the specific collection rule information software service, which is convenient for adding and maintaining. The architecture design is used as a software servitization foundation, and not only needs to consider to complete the current function in the initial stage of the construction, but also needs to consider the robustness of the software and the coupling degree between modules so as to increase and reduce the life cycle of the software and reduce the maintenance cost of the software. However, data acquisition software designed by a software architecture can often be designed only for a specific protocol, so that 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 reused and flexible expansion cannot be realized.

Disclosure of Invention

In view of the above drawbacks of the prior art, the present invention provides an obtaining method of a vehicle cloud data collecting system architecture, so as to solve the problems that the life cycle of software is reduced, the maintenance cost is increased, and data collection can only be performed for a specific protocol.

The invention provides a method for acquiring a vehicle cloud data acquisition system architecture, which comprises the following steps:

the method comprises the steps that through analysis of business requirements of a vehicle cloud data acquisition system architecture, information of business cases of the vehicle cloud data acquisition system architecture is obtained;

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;

splitting a plurality of functions to be realized by the business concepts in steps, and acquiring information of field services of the vehicle cloud data acquisition system architecture;

arranging the information of the domain service, and acquiring the information of interface protocols interacted with the ports of a plurality of plug-in adapters; and

and according to the information of the interface protocol, a plurality of plug-in adapters interact with the vehicle cloud data acquisition system.

In an embodiment of the present invention, the obtaining information of the 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 by analyzing the service requirement of the vehicle cloud data acquisition system; and

and dividing the boundary of the vehicle cloud data acquisition system to acquire the information of a plurality of service cases.

In an embodiment of the present invention, the obtaining information of the domain model of the vehicle cloud data acquisition system architecture includes the following steps:

acquiring the information of key problems in the service cases by splitting a plurality of service cases;

and acquiring the information of the domain model by extracting the information of the key problems in the service use case.

In an embodiment of the present invention, the method further includes the following steps:

acquiring new type of vehicle-mounted data;

and acquiring port information of a new plug-in adapter matched with the new type of the vehicle-mounted data.

arranging the information of the field service, and acquiring the information of an interface protocol interacted with the port of the new plug-in adapter;

and 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 an embodiment of the present invention, the obtaining information of the interface protocol interacting with the ports of the plurality of plug-in adapters includes the following steps:

acquiring port information of a warehousing adapter;

acquiring port information of an acquisition rule adapter;

acquiring port information of a front-end user interface adapter; and

and acquiring the port information of the external system adapter.

arranging the information of the field service according to the port information of the warehousing 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 interface protocols interacting with the port of the warehousing 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 case acquisition module, a service case acquisition module and a service case management module, 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 system comprises a field model acquisition module, a field model acquisition module and a field model analysis module, wherein the field model acquisition module is used for splitting information of a plurality of service cases to acquire information of a field model of a vehicle cloud data acquisition system architecture and information of a plurality of service concepts in the field model;

the system comprises a field service acquisition module, a cloud data acquisition system and a cloud service management module, wherein the field service acquisition module is used for splitting a function to be realized by a plurality of business concepts in steps and acquiring the information of the field service of the vehicle cloud data acquisition system architecture;

the interface protocol acquisition module is used for arranging the information of the field service and acquiring the information of the interface protocol interacted with the ports of the plurality of plug-in adapters; and

and the interaction module is used for interacting the plurality of plug-in adapters and the vehicle cloud data acquisition system according to the information of the interface protocol.

The invention provides an electronic device, comprising:

at least one processor;

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 device is enabled to realize the acquisition method of the vehicle cloud data acquisition system architecture.

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 enabled to execute any one of the above-mentioned methods for acquiring the vehicle cloud data acquisition system architecture.

The invention has the beneficial effects that: the invention supports the addition of various types of data in the form of a plug-in adapter, thereby achieving the acquisition and analysis of data in different formats. When a new data type is accessed, only one new plug-in adapter needs to be realized for interactive connection, 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 frequently-changed service demand scenes, and is beneficial to prolonging the life cycle of the system and reducing the maintenance cost of the system.

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.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort. In the drawings:

fig. 1 is a schematic application environment diagram of an acquisition method of a vehicle cloud data acquisition system architecture according to an exemplary embodiment of the present application;

fig. 2 is a flowchart illustrating an acquisition method of a vehicle cloud data acquisition system architecture according to an exemplary embodiment of the present application;

fig. 3 is a flowchart of a method for acquiring a service use case according to an exemplary embodiment of the present application;

FIG. 4 is a flow diagram of a method for obtaining business concepts as shown in an exemplary embodiment of the present application;

FIG. 5 is a flow chart illustrating a method for data collection after a new type of data access, according to an exemplary embodiment of the present application;

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.

FIG. 7 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.

Detailed Description

Other advantages and effects of the present invention will become apparent to those skilled in the art from the disclosure herein, wherein the embodiments of the present invention are described in detail with reference to the accompanying drawings and preferred embodiments. The invention is capable of other and different embodiments and of being practiced or of being carried out in various ways, and its several details are capable of modification in various respects, all without departing from the spirit and scope of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention, and are not intended to limit the scope of the present invention.

It should be noted that the drawings provided in the following embodiments are only for illustrating the basic idea of the present invention, and the drawings only show the components related to the present invention rather than being drawn according to the number, shape and size of the components in actual implementation, and the type, amount and proportion of each component in actual implementation can be changed freely, and the layout of the components can be more complicated.

In the following description, numerous details are set forth to provide a more thorough explanation of embodiments of the present invention, however, it will be apparent to one skilled in the art that embodiments of the present invention may be practiced without these specific details, and in other embodiments, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring embodiments of the present invention.

It should be noted that, firstly, a software architecture (software architecture) is a series of relevant abstract modes for guiding the design of various aspects of a large software system. The software architecture is a sketch of a system, and the objects described by the software architecture are abstract components that directly constitute the system. The connections between the various components are explicitly and relatively carefully described as to the communication between the components. During the implementation phase, these abstract components are refined to actual components, such as concrete classes or objects. In the object-oriented domain, connections between components are typically implemented with interfaces. When a system with complex services needs to be constructed, not only a robust technical architecture needs to be constructed from a technical perspective, but also a service architecture needs to be constructed if service requirements which can be met by the system need to be ensured. The DDD (Domain Driven Design) integrates a technical architecture and a business architecture, and can embody system business and guide development of technical codes.

The field-driven design can split the complex problem, and split the association among the subsystems, how the subsystems operate and how the subsystems are associated with each other, so that the principle that a large-scale complex system is required to follow when falling to the ground is solved. The domain-driven 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 bears service attributes and concrete behaviors and is a service expression method, and the domain model is a class-specific attribute which comprises a setting attribute and an obtaining attribute. The behavior operation of the service is also a service logic operation in the model class, which is also called a data transmission object. The domain model includes three types of entities, value objects, and services. The hierarchical structure of the domain-driven design comprises a user interface layer, an application layer, a domain layer and a basic implementation layer.

Fig. 1 is a schematic application environment 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 requirement of the vehicle cloud data acquisition system architecture, the connection between the service requirements, and the steps of implementing the functions to be implemented by the service requirement, 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 to complete the vehicle cloud data acquisition system, i.e., the vehicle cloud data acquisition application 130, 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 to the vehicle cloud data acquisition application 130 through an interface of the vehicle cloud data acquisition application 130 to transmit data to the vehicle cloud data acquisition application 130 or to call 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 acquisition system architecture acquisition module 110, and the vehicle cloud data acquisition 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 providing basic cloud computing services such as cloud service, a cloud database, cloud computing, a cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, CDN (Content Delivery Network), and a big data and artificial intelligence platform, which is not limited herein. The vehicle cloud data acquisition application 130 and the three-party service 140 can communicate with each other through wireless networks such as a 3G (third-generation mobile information technology), a 4G (fourth-generation mobile information technology), a 5G (fifth-generation mobile information technology) and the like, and the embodiment of the application does not limit the operation, and can be set according to actual requirements.

In some embodiments, the existing data acquisition software designed through a software architecture is often designed only for a specific protocol, so that 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 reused and flexible expansion cannot be achieved. In order to solve the problems, embodiments of the present application respectively provide an acquisition method, an apparatus, a device, and a medium for 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 obtaining method of a vehicle cloud data collecting system architecture according to an exemplary embodiment of the present application. In some embodiments, the method may be applied to the implementation environment shown in fig. 1, and is specifically executed by the obtaining module 110 of the vehicle cloud data acquisition system architecture in the implementation environment. It should be understood that the method may be applied to other exemplary implementation environments and is specifically executed by devices in other implementation environments, and the embodiment does not limit the implementation environment to which the method is applied.

For example, an SDK (Software Development Kit, which is a Development tool set used when establishing application Software for a specific Software package, a Software framework, an operating system, and the like) may be installed in the obtaining module 110 of the vehicle cloud data acquisition system architecture to which the obtaining method of the vehicle cloud data acquisition system architecture disclosed in this embodiment is applied, and the method disclosed in this embodiment is specifically implemented as one or more functions externally provided by the SDK.

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 cases of a plurality of vehicle cloud data acquisition systems by analyzing service requirements of the vehicle cloud data acquisition systems.

Firstly, it is required to analyze the service requirements of the vehicle cloud data acquisition system architecture, and then divide the boundary of the vehicle cloud data acquisition system, so as to extract the service cases. The service case expresses the requirements of the user on the vehicle cloud data acquisition system, and defines the boundary of the vehicle cloud data acquisition system and the interaction scene of the external role and the system of the vehicle cloud data acquisition system. The main service cases in the system comprise service cases for uploading data of various specifications by a collection vehicle, 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 the application range of the model is defined.

Step S220, splitting the information of the plurality of service cases, and acquiring the information of the field model of the vehicle cloud data acquisition system architecture and the information of the plurality of service concepts in the field model.

By splitting the service case, key problems in the service case are obtained, and a 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 concept, and converting the conceptual model into the domain model. The acquisition mode of the model in the field comprises a brainstorming storm and an experiment, so that the service concept used in the vehicle cloud data acquisition system is abstracted. The business concept comprises a structured data concept, a semi-structured data concept and an unstructured data concept.

The field model is an abstraction of a field with a certain boundary, the field model only reflects services, is irrelevant to the realization of task technology, reflects the essence of service requirements of users in the field, and is an abstraction aiming at service concepts in the vehicle cloud data acquisition system.

Step S230, splitting the functions to be implemented by the multiple service concepts, and acquiring information of the field service 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 concepts, and obtaining a plurality of steps included in the functions for realizing the service requirements. And then, refining the multiple steps to extract multiple key steps, and correspondingly acquiring the key steps to a vehicle cloud data acquisition system, so that the multiple key steps for realizing the business requirements are refined into the capacity of the field service. Moreover, the part of the capacity is atomic, so that the capacity responsibility in the domain service is single and can not be divided, and a plurality of domain services can be called to realize a task specific to a certain domain.

Among them, the domain service has three features, the first one is to emphasize a stateless operation, the state should be maintained in the entity, and the domain service process is a stateless logical process. The second feature is the task of implementing a domain, what is done is within the domain boundaries. The domain service is not an Application service, the Application service is a client side of the domain service, such as an API (Application Programming Interface) aggregation service, and the Application service does not do things in the domain. The third feature is to consider modeling of the aggregate or value object first, and only use the domain service if a certain operation is not suitable for placing on the aggregate or value object. The field service refers to abstraction of functions which can be completed by a vehicle cloud data acquisition system, the field service is a collection of all core business functions which can be completed by the system, and the field service comprises functions of intelligent identification, transmission, monitoring, preprocessing, management and the like of data.

Step S240, arranging the information of the domain services, and acquiring the information of the interface protocol interacting with the ports of the plurality of plug-in adapters.

The capability provided by the domain service is atomic, so that the business requirement of the vehicle cloud data acquisition system architecture needs to be adapted through arranging and combining 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 used for extracting core business objects and core business logic of the vehicle cloud data acquisition system and comprises domain objects and domain services. 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 responsibility for the organization and orchestration of domain objects and domain services. Wherein the plug-in adaptation layer comprises a plurality of plug-in adapters. Because the application layer and the field layer do not care which technologies are used specifically, only the input object data need to be obtained, and the output object data information required by the interface of each plug-in adapter is constructed in an aggregation manner. Therefore, after port information of a plurality of plug-in adapters, such as port information of a warehousing adapter, port information of a collection rule adapter, port information of a front-end user interface adapter and port information of an external system adapter, is acquired, by arranging domain services, an interface protocol interacting with the plug-in adapters is established in an application program layer, and data specifications of input items and output items are specified. The advantage of this is that each module is decoupled, thus realizing single responsibility, supporting the collection and uploading of various data rules, and interacting functions with different systems. When data needing analysis is newly increased or changed, only the plug-in adapter needs to be flexibly expanded, and the method has the characteristics of multiplexing key components and flexibly expanding.

The plug-in adaptation layer comprises a storage adapter, a collection rule adapter, a front end UI (User Interface) adapter and an external system adapter. The warehousing adapter is mainly interactive with data storage, and the data storage comprises a relational database, a non-relational database, files and the like. The acquisition rule adapter adapts data formats with different specifications according to a uniform interactive interface specification provided by an application layer, and interacts the adapted data with the application layer, so that the aims of recognizing a plurality of different data formats by a system and carrying out subsequent service processing are fulfilled. The front-end UI adapter and the acquisition rule adapter are hierarchically at the same level, display and interact different data types, and display data on a front-end UI interface or upload data to the vehicle cloud data acquisition system. The external system adapter mainly realizes data interaction, function call and the like with other systems.

And S250, interacting the plurality of plug-in adapters and the vehicle cloud data acquisition system according to the information of the interface protocol.

The vehicle cloud data acquisition system is arranged on an application program layer, and in order to convert input and output items of other systems or three-party services into data formats which can be identified by the application program layer and a field layer, a plurality of plug-in adapters are required to convert the data formats through the plug-in adapters according to interface specifications established by the application program layer, so that 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 field layer which are different from the most core business logic processing part in the vehicle cloud-end data acquisition system, and mainly comprises data storage, a data acquisition rule, a UI (user 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. The part serving as the most core part can be modified little or not after the software design is finished. Because of the existence of the internal interactive interface protocol, the change is mainly in the plug-in adapter layer, and the layer is mainly responsible for adapting the externally changed data into the data conforming to the internal interface specification, so that when every new data needs to be collected, the data to be collected only needs to be 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 flow flows from the plug-in adapter layer to the application layer, and the business process is performed by the domain service. The plug-in adapter and the vehicle cloud data acquisition system are interacted through the interface protocol, the interaction is not limited to the acquisition of data of multiple different formats generated by multiple three-party services, and the interaction can be realized by adapting a UI (user interface), data storage and data analysis of a three-party data analysis system in a similar plug-in adapter mode.

Fig. 3 is a flowchart of a method for acquiring a service use case according to an exemplary embodiment of the present application. As shown in fig. 3, in an exemplary embodiment, the method for acquiring a service use case at least includes steps S310 to S330, which are described in detail as follows:

step S310, obtaining the information of the service requirement of the vehicle cloud data acquisition system.

Step S320, analyzing the information of the service requirement to obtain boundary information of the vehicle cloud data acquisition system.

The boundary of the vehicle cloud data acquisition system is a bound context, and the application range of the model is defined. .

Step S330, the boundary of the vehicle cloud data acquisition system is divided, and information of a plurality of service cases is acquired.

The main service cases in the vehicle cloud data acquisition system comprise service cases for acquiring data of various specifications uploaded by a vehicle, service cases for identifying vehicle-mounted data, service cases for analyzing and sending processed data and the like.

Fig. 4 is a flowchart illustrating 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 acquiring the service concept at least includes steps S410 to S420 as follows:

step S410, by splitting multiple service cases, information of key problems in the service cases is obtained.

Step S420, extracting the information of the key problem in the service case to obtain the information of the domain model.

The method comprises the steps of splitting a service case, obtaining key problems in the service case, and extracting a field concept of a vehicle cloud data acquisition system from the key problems. And then obtaining a conceptual model according to the domain concept, and converting the conceptual model into the domain model. The field model is an abstraction of a field with a certain boundary, the field model only reflects services, is irrelevant to the realization of task technology, reflects the essence of service requirements of users in the field, and is an abstraction aiming at service concepts in the vehicle cloud data acquisition system.

Fig. 5 is a flowchart illustrating a method for acquiring data after a new type of data access according to an exemplary embodiment of the present application. As shown in fig. 5, in an exemplary embodiment, after accessing the new type of data, the data collection method at least includes steps S510 to S530 as follows:

in step S510, new types of vehicle-mounted data are acquired.

The third party service such as an automatic navigation system can be externally connected, and the automatic navigation system can generate new types of vehicle data.

Step S520, acquiring port information of the new plug-in adapter matched with the new type of vehicle data.

For example, the auto-navigation system may match the auto-navigation adapter, i.e., the new plug-in adapter.

Step S530, arranging the information of the domain service, and acquiring the information of the interface protocol interacted with the port of the new plug-in adapter.

The capability provided by the domain service is atomicity, so that the business requirement of the vehicle cloud data acquisition system architecture can be adapted through arrangement and combination of the domain service. And obtains the interface protocol interacting with the port of the new plug-in adapter.

And S540, interacting the new plug-in adapter and the vehicle cloud data acquisition system according to the information of the interface protocol, and acquiring and analyzing the new type of vehicle-mounted data by the vehicle cloud data acquisition system.

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 apparatus may be applied to the application environment shown in fig. 1, and is specifically configured in the obtaining module 110 of the vehicle cloud data acquisition system architecture. The apparatus may also be applied to other exemplary implementation environments, and is specifically configured in other devices, and the embodiment does not limit the implementation environment to which the apparatus is applied.

As shown in fig. 6, the exemplary data security storage device includes:

the use case acquisition module 610 is configured to acquire information of the service use cases of the plurality of vehicle cloud data acquisition system architectures through analysis of service requirements of the vehicle cloud data acquisition system architectures; the domain model obtaining module 620 is configured to split information of a plurality of service cases, and 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; the domain service acquisition module 630 is configured to split the functions to be implemented by the multiple service concepts in steps, and acquire domain service information of the vehicle cloud data acquisition system architecture; an interface protocol acquiring module 640, configured to arrange information of the domain service and acquire information of interface protocols interacting with ports of the multiple plug-in adapters; and an interaction module 650, configured to interact the plurality of plug-in adapters with the vehicle cloud data collection system according to the information of the interface protocol.

FIG. 7 illustrates a schematic structural diagram of a computer system suitable for use to implement the electronic device of the embodiments of the subject 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 bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 7, the computer system 700 includes a Central Processing Unit (CPU) 701, which can perform various appropriate actions and processes, such as executing 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 section 708 into a Random Access Memory (RAM) 703. In the RAM 703, various programs and data necessary for system operation are also stored. The CPU 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. An Input/Output (I/O) interface 705 is also connected to the bus 704.

The following components are connected to the I/O interface 705: an input portion 706 including a keyboard, a mouse, and the like; an output section 707 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; 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, or the like. The communication section 709 performs communication processing via a network such as the internet. A 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 mounted on the drive 710 as necessary, so that a computer program read out therefrom is mounted into the storage section 708 as necessary.

In particular, according to embodiments of the application, the processes described above with reference to the flow diagrams 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 illustrated by the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 709, and/or installed from the removable medium 711. The computer program executes various functions defined in the system of the present application when executed by a Central Processing Unit (CPU) 701.

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 of the foregoing. More specific examples of the 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 (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 propagated data signal with a computer-readable computer program embodied therein, either in baseband or as part of a carrier wave. 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 thereof. 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. The computer program embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowchart 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. 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 described 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 disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

Another aspect of the present application further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor of a computer, causes the computer to execute the method for acquiring the 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 assembled into 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 instruction from the computer-readable storage medium, and executes the computer instruction, so that the computer device executes the obtaining method of the vehicle cloud data acquisition system architecture provided in the above embodiments.

The foregoing embodiments are merely illustrative of the principles of the present invention and its efficacy, and are not to be construed as limiting the invention. Any person skilled in the art can modify or change the above-mentioned embodiments without departing from the spirit and scope of the present invention. Accordingly, it is intended that all equivalent modifications or changes which can be made by those skilled in the art without departing from the spirit and technical spirit of the present invention be covered by the claims of the present invention.

Claims

1. A method for acquiring a vehicle cloud data acquisition system architecture, the method comprising:

the method comprises the steps that the service requirements of a vehicle cloud data acquisition system are analyzed, and the information of service cases of a plurality of vehicle cloud data acquisition systems is obtained;

splitting the information of the plurality of service cases to acquire the information of a field model of a vehicle cloud data acquisition system architecture and the information of a plurality of service concepts in the field model;

arranging the information of the field service, and acquiring the information of interface protocols interacting with the ports of a plurality of plug-in adapters; and

2. The method according to claim 1, wherein the step of obtaining the information about the service cases of the vehicle cloud data acquisition system architecture includes:

3. The method of claim 1, wherein the step of obtaining the information of the domain model of the vehicle cloud data acquisition system architecture comprises:

acquiring information of key problems in the service use cases by splitting a plurality of service use cases;

and extracting the information of the key problems in the service use case to obtain the information of the domain model.

4. The method of claim 1, further comprising the steps of:

acquiring new type of vehicle-mounted data;

5. The method of claim 4, further comprising the steps of:

6. The method of claim 1, wherein the step of obtaining information of interface protocols interacting with the ports of the plurality of plug-in adapters comprises:

acquiring port information of a warehousing adapter;

acquiring port information of an acquisition rule adapter;

acquiring port information of a front-end user interface adapter; and

and acquiring the port information of the external system adapter.

7. The method of claim 6, wherein the step of obtaining information of interface protocols interacting with the ports of the plurality of plug-in adapters comprises:

8. An acquisition device of a vehicle cloud data acquisition system architecture, the device comprising:

the system comprises a use case acquisition module, a service request processing module and a service request processing module, wherein the use case acquisition module is used for acquiring information of a plurality of service use cases of a vehicle cloud data acquisition system architecture through analysis of service requirements of the vehicle cloud data acquisition system architecture;

the system comprises a field model acquisition module, a field model acquisition module and a field model management module, wherein the field model acquisition module is used for splitting information of a plurality of service cases to acquire information of a field model of a vehicle cloud data acquisition system architecture and information of a plurality of service concepts in the field model;

9. An electronic device, the electronic device comprising:

at least one processor;

a storage device for storing at least one program, which when executed by the at least one processor, causes the electronic device to implement the acquisition method of the vehicle cloud data acquisition system architecture of any one of claims 1 to 7.

10. A computer-readable storage medium, having a computer program stored thereon, wherein when executed by a processor of a computer, the computer program causes the computer to execute the method for acquiring the vehicle cloud data acquisition system architecture according to any one of claims 1 to 7.