CN115454384A

CN115454384A - Domain design method for software defined automobile service development process

Info

Publication number: CN115454384A
Application number: CN202211197985.2A
Authority: CN
Inventors: 朱凯; 邓若冰
Original assignee: Jiangsu Hoperun Software Co ltd
Current assignee: Jiangsu Hoperun Software Co ltd
Priority date: 2022-09-29
Filing date: 2022-09-29
Publication date: 2022-12-09

Abstract

The invention provides a field design method of a software-defined automobile service development process, which is characterized by comprising three parts of module division, field modeling and model verification, wherein after the requirements are determined, the business field is sorted and divided according to a business model and a function point of a thermal management module, all field objects in the thermal management field are distinguished, all field models included in the thermal management sub-field are determined, each model is designed in detail, and a summary design document and a UML class diagram are correspondingly output and comprise an association relation; the invention completes module division by using the thought of domain modeling, converts the domain model into the development model, makes the module division more detailed, makes the whole development work division more clear, ensures the accuracy of business division, and has high cohesion and low coupling among business modules.

Description

Domain design method for software defined automobile service development process

Technical Field

The invention relates to the field of automobile service, in particular to a field design method for a software-defined automobile service development process.

Background

With the gradual advance of intelligent automobiles, the complexity of software and hardware of the automobile body is continuously improved, the research and development cost is rapidly increased, and a plurality of new functions need to be added to the existing whole automobile software system along with the continuous adjustment of the demand. Because the software service logic cannot be controlled and a perfect expansion system is not provided, the software product cannot be iterated stably. Butterfly effect is easily caused in each service upgrading process, and other module functions are easily involved to cause a large number of accidents, so that the stability of the whole vehicle is influenced.

Service development of the automobile industry can completely reference the software industry, the development of the software industry is subjected to iterative updating for decades, a plurality of mature methodologies are formed, the automobile industry has industry consensus on transformation of software-defined automobiles, the software-defined automobiles are still in a starting stage, and a large amount of introduced software brings a series of challenges to the automobile industry from design, development, integration, test, release and maintenance. Only by managing the complexity of the software and hardware combination, the experience requirements of consumers can be continuously met, and the market competitiveness is formed.

Due to the particularity of the automobile industry, most services may be bound with specific hardware devices, which requires that the definition of service api needs very high reusability to adapt to different bottom layer hardware, and because the development mode of the automobile industry is more traditional, the service api is very difficult to adapt to the requirements of the existing rapidly-developed automobiles, which requires a mature idea to guide the development of the whole automobile industry.

Layered decoupling is a key means for improving software reusability and reducing software and hardware development complexity at present, and is a necessary route for defining an automobile by stepping software. Through layered decoupling, software and hardware can be separated, and application and a basic platform are separated, but how to implement becomes a key challenge, and strategic targets and values of software defined automobiles are directly influenced. From the technical aspect, how the architecture is layered and how the services are divided is beneficial to maximizing multiplexing, simplifying development and maintenance and long term evolution; the software defined automobile value can be maximized only through reasonable, stable and uniform service division; from the aspect of an industrial chain, how each party can position, divide labor and cooperate to ensure that each party can maximize benefits is a key difficulty, and openness, cooperation and win-win are the basis of software definition for the rapid landing of the automobile.

In the current service development process, a unified development mode and development idea are not available, communication among all departments is difficult, and part of requirements cannot be accurately transmitted, so that the development progress cannot be normally promoted and reworked frequently when the requirements are continuously changed (the whole vehicle field is rapidly developed), and the quality cannot be guaranteed; the service boundary is not clear, so that partial functions are mixed in a plurality of services, thereby causing the condition of mutual interference in the specific development process, and how to ensure that the subsequent iteration can be directly expanded along with the increase of the demand is also an urgent problem to be solved.

Disclosure of Invention

The invention aims to provide a field design method for a software defined automobile service development process, which aims to solve the problems in the background technology.

In order to achieve the purpose, the invention provides the following technical scheme:

a field design method for a software-defined automobile service development process comprises the following steps:

s1, determining requirements, understanding market requirements through requirement analysis and requirement research, and determining whether the requirement points corresponding to all service models can be realized through requirement feasibility analysis;

s2, designing a domain, namely creating a reliable domain model through module division, domain modeling and model verification to prepare for service development;

s3, service development, including model development and verification, is carried out to complete specific function development in the field of thermal management;

s4, testing and issuing, integrating testing and issuing, mainly completing the verification of the function, and correspondingly issuing to a software and hardware platform after the verification is completed;

and S5, continuously expanding, expanding new requirements, and continuously updating and iterating.

In step S1, the requirement investigation specifically includes:

communicating with a client business expert, sorting the requirements, deeply combing the requirements step by step, sorting out an original business model which comprises a rough functional point of a thermal management module, and determining the logic flow relation of the whole business; in the process, the consistency with a customer service expert is required to be ensured, and a demand analysis report and a UML use case are output;

the demand analysis is specifically based on the following four aspects:

(1) the reason for the generation of the demand is to clearly determine why the demand is generated, which is beneficial to fully understanding the demand and provides help for the subsequent identification of the authenticity of the demand;

(2) a scene is required to be used, namely a www (www where) principle, namely, a person/thing can use the requirement at any time and place, so that a better design function is facilitated, and the defect of insufficient expansibility of the designed function is avoided; and expanding thinking through the scene of the demand side, and judging whether a derivative scene exists. The process of thinking, and the process of helping you grasp and understand the nature of the demand;

(3) distinguishing true and false requirements, determining the idea of a demand proposing person, after fully understanding the requirements, replying several rounds with the demand proposing person, and listening to the opinions and suggestions of the demand proposing person from the perspective of a user; through the process, the demand points and the implementation modes are basically agreed, and a lot of obstacles are reduced during later formal development;

(4) the demand solution scheme is used for determining product demands, finding out common points for realizing certain demands and laying a foundation for field modeling. When considering the preliminary demand solution, not only the user side but also the strategic, product operation, business and competitive sides are considered.

In the step S1, the demand feasibility analysis specifically includes four aspects, specifically including:

(1) the technical feasibility aims to judge whether a new system can be realized under the current technical condition or whether a certain new technology can be obtained under a specific condition;

(2) the feasibility of the organization, which is to study whether the proposed service function can be successfully realized;

(3) time feasibility, whether the service function can be developed and completed within the specified time;

(4) economic feasibility, cost and benefit of research and development, and whether the obtained benefit can be higher than the development cost and whether the development cost can be recovered within a specified time is judged;

and determining whether the demand points corresponding to all the service models in the demand research can be realized or not according to the four aspects.

The module division in step S2 specifically includes the following contents:

after step S1 is completed, according to the service model and the function points of the thermal management module, the service domain is sorted and divided, all domain objects in the thermal management domain are distinguished, all domain models included in the thermal management sub-domain are determined, each model is designed in detail, and a summary design document and a UML class diagram (including an association relationship) are correspondingly output, and the specific domain modeling can be performed according to the following steps:

s2.1, after the step S1 is finished, further analyzing and disassembling the requirements to determine the problem domain and the service expectation, and classifying the problem domain by combining the service view; and completing a corresponding finished automobile heat management assembly diagram through a unified uml language:

s2.2, finding out all entities (carriers bearing thermal management business functions), value objects and attributes in the entities in each component in the thermal management field, and finishing uml class diagram design;

specifically, the steps of constructing the thermal management module entity by using a four-color modeling method are as follows:

s2.2.1, determining a time mark type object, namely, a footprint is left in the whole event; these footprints are all time stamped objects. These objects are the starting points for the modeling (e.g., temperature, pm 2.5);

s2.2.2, and S2.2.1, namely, participants who supplement some entity objects and time-scale objects generally have three types, objects, places and objects (such as a temperature sensor and a temperature controller);

s2.2.3, how to join role objects, namely entity objects in the S2.2.2, into a specific flow, namely actions of the entities;

s2.2.4, adding some proper description objects which also belong to an entity;

to summarize, for the construction of an entity, firstly, on the premise of meeting the requirements of management and operation, some events needing to be traced are searched, participants are searched according to the events, and then some specific actions of role objects are abstracted from the participants; finally, for some complex scenes, some descriptive objects need to be true and false to complement;

s2.3, forming aggregation of the domain objects in the step S2.2 according to the business relation through the business relation in the uml component diagram, and then determining aggregation roots, wherein each aggregation root corresponds to one domain model, and the access to the objects in all the domains needs to pass through the aggregation roots;

s2.4, returning to the combing service, semantic boundary and defining boundary context.

The S2.3 and S2.4 are mainly used for combing the business process through the event storm and determining the business boundary, and specifically comprise the following steps:

s2.4.1, identifying field events, mainly tracing past sound events; for example, the temperature has changed, the water temperature has changed

S2.4.2, recognizing commands, wherein the commands mainly aim at the operation of different main bodies under different Yangtze rivers; for example, the temperature is increased and reduced, and a water pump is turned on;

s2.4.3, finding aggregation, finding a corresponding aggregation boundary by combining commands and events and combining a uml component diagram, and identifying the commands and the events distributed at different positions on a time axis;

s2.4.4, an aggregation is probably the boundary context of the minimum granularity, and in general, the aggregation with high relevance is combined to form a new aggregation.

The domain modeling in the step S2 specifically includes the following contents:

on the basis of completing module division, fullness of objects in each field of the whole vehicle thermal management needs to be completed, and corresponding specific variables, parameters and final operation logic in a class diagram are perfected; the step is closely related to the development process, namely, a domain model is converted into a development model, and a UML class diagram, a UML state diagram, a UML time sequence diagram, a UML collaboration diagram and a UML activity diagram are correspondingly output;

the design of the timing diagram can be realized according to the following steps:

a. defining the goals and tasks of the physical object (e.g. the function of the temperature sensor is to output the temperature value and the state value under abnormal condition)

b. Analyzing the existing resources and environment points, and determining the objects involved in the calling process. (e.g., temperature control service)

c. Listing the main matters designed in the flow, and carrying out a preliminary arrangement (for example: atomic service call equipment abstraction)

d. Analyzing the thinning sequence of each item and the time and permission links of your arrangement flow.

The model verification in step S2 specifically includes the following:

after the domain modeling is completed, the business model function is reversely deduced through the domain model, and whether the current domain model can realize all business functions is judged; the method is a one-time check on the rationality of the field model to ensure the completeness of the field model.

The model development and verification in step S3 specifically includes the following:

according to the UML state diagram, the UML time sequence diagram and the UML cooperation diagram, the specific function development of the thermal management field is completed, the infrastructure layer, the field layer, the interface layer and the application layer in a thermal management field model are specifically realized, meanwhile, according to the business condition, a corresponding extension layer is set, and the extension is reserved in advance to prepare for the future; managing the development process, namely outputting a product of each stage corresponding to each stage according to the agile development management model; the process finally outputs codes and corresponding development manuals;

the agile development in the whole vehicle thermal management development process comprises the following steps:

s3.1, a heat management module product responsible person is responsible for determining a product demand pool;

s3.2, performing workload prediction and arrangement by an agile team according to a product demand pool, and performing division of labor to form a ventilation control group, a temperature control group, an equipment heat dissipation group and an environment monitoring group;

s3.3, a product demand pool is provided, and each group needs to select some product demand pools from the product demand pools through an iteration plan conference to add iteration to form an iteration demand pool; the time period for this target is 1-4 weeks;

s3.4, the iteration demand pool is completed by each group of the agile team, and each member of the group is refined into smaller tasks according to the iteration demand pool (the workload of each task can be completed within 2 days);

and S3.5, in the process of completing the iteration requirement pool selected from the plan meeting by the agile team, a daily standing meeting is required to be carried out, and each meeting is controlled within 15 minutes. Daily standing meetings each person speaks according to the content of the kanban and reports to all members on the fly what was done yesterday, what is to be done today, and can be proposed if an unsolvable problem is encountered. After each person finishes answering, the burnout map needs to be updated;

s3.6, when the iteration demand pool is finished, one iteration is finished; at the moment, an iterative review conference is carried out, and both a person in charge of the thermal management module product and a client participate; each member of the agile team will demonstrate to them the software product that they have completed (this meeting is important and must not be cancelled);

and S3.7, finally, carrying out an iterative review conference, wherein the conference is carried out in a manner of speaking in turn, everyone speaks, summarizes and discusses the improved places, and puts the improved places into the product requirements of the next iteration.

The step S4 specifically includes the following contents:

the step mainly completes the functional verification, including functional verification, performance verification and safety verification, and correspondingly releases the verification to the software and hardware platform; the step can be integrated with a mature ci/cd platform for uniformly managing the testing, issuing and upgrading processes, and the process of testing the functions can be guaranteed to be completed before issuing and upgrading; this process ultimately outputs a test report and a uml configuration diagram.

The step S5 is realized by field-driven layering, an extension layer is reserved in advance, and input for a new requirement is completed by the advance of the extension layer, but the overall steps need to complete requirement determination, requirement investigation, requirement analysis, field modeling, model design, service development, and test release in sequence.

Compared with the prior art, the invention has the following beneficial effects:

the invention completes module division by using the thought of domain modeling, converts the domain model into the development model, makes the module division more detailed, makes the whole development work division more definite, ensures the accuracy of business division, and ensures high cohesion and low coupling between business modules

Drawings

FIG. 1 is a general flow diagram of the present invention;

FIG. 2 is a diagram of a demand analysis report and UML use case output by the present invention;

FIG. 3 is a diagram of the present invention for implementing thermal management components corresponding to a finished vehicle in unified uml language;

FIG. 4 is a uml class diagram design of the present invention;

FIG. 5 is a timing diagram of the UML of the present invention;

FIG. 6 is a partial screenshot of the development manual of the present invention;

FIG. 7 is a diagram of the output test report and uml configuration of the present invention.

Detailed Description

The present invention will be described in further detail with reference to the following examples in order to clarify technical problems, technical solutions, implementation processes and performance displays. It should be understood that the specific embodiments described herein are for illustrative purposes only. The present invention is not limited to the above embodiments. Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers can indicate functionally identical or similar elements. While the various aspects of the embodiments are presented in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

The word "exemplary" is used exclusively herein to mean "serving as an example, embodiment, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

Furthermore, in the following detailed description, numerous specific details are set forth in order to provide a better understanding of the present disclosure. It will be understood by those skilled in the art that the present disclosure may be practiced without some of these specific details. In some instances, methods, means, elements and circuits that are well known to those skilled in the art have not been described in detail so as not to obscure the subject matter of the present disclosure.

Example 1

As shown in fig. 1, a field design method for a software-defined automotive service development process includes the following steps:

s1, determining the demand, understanding the market demand through demand analysis and demand research, and determining whether the demand points corresponding to all the service models can be realized through demand feasibility analysis;

s3, service development, including model development and verification, is performed to complete specific function development in the field of thermal management;

In step S1, the requirement investigation specifically includes:

communicating with a client business expert, sorting the requirements, and further sorting the requirements step by step to obtain an original business model which comprises the approximate function points of the thermal management module and defines the logical flow relationship of the whole business; this process, which needs to be guaranteed to be in agreement with the customer service expert, outputs a requirement analysis report and UML use case, as shown in fig. 2;

the demand analysis is specifically based on the following four aspects:

(4) the demand solution scheme is used for determining product demands, finding out common points for realizing certain demands and laying a foundation for field modeling. When considering the solution of the preliminary requirement, not only the user side but also the strategy, product operation, business and competitors need to be considered.

The module division in step S2 specifically includes the following contents:

s2.1, after the step S1 is finished, further analyzing and disassembling the requirements to determine the problem domain and the service expectation, and classifying the problem domain by combining the service view; and completing a corresponding finished automobile heat management assembly diagram through a unified uml language, as shown in fig. 3:

s2.2, finding out all entities (carriers bearing thermal management business functions), value objects and attributes in the entities in each component in the thermal management field, and completing design of the uml class diagram, as shown in FIG. 4;

s2.2.1, determining a time mark type object, namely, leaving a footprint in the whole event; these footprints are all time-stamped objects. These objects are the starting points for the modeling (e.g., temperature, pm 2.5);

s2.2.4, adding some proper description objects, and belonging to an entity;

to summarize, for the construction of an entity, firstly, on the premise of meeting the requirements of management and operation, some events needing to be traced are searched, participants are searched according to the events, and some specific actions of role objects are abstracted from the participants; finally, for some complex scenes, some descriptive objects need to be true and false to complement;

s2.3, forming aggregation of the field objects in the step S2.2 according to the business relation through the business relation in the uml component diagram, and determining aggregation roots, wherein each aggregation root corresponds to one field model, and the access to the objects in all the fields needs to pass through the aggregation roots;

s2.4.1, identifying field events, mainly tracing past sound events; for example, the temperature has changed and the water temperature has changed

S2.4.2, recognizing commands, wherein the commands mainly aim at the operation of different main bodies under different Yangtze rivers; for example, the temperature is increased, the temperature is reduced, and a water pump is turned on;

on the basis of completing module division, fullness of objects in each field of the whole vehicle thermal management needs to be completed, and corresponding specific variables, parameters and final operation logic in a class diagram are perfected; the step closely associates the development process, i.e. the domain model is converted into the development model, and correspondingly outputs a UML class diagram, a UML state diagram, a UML timing diagram (as shown in FIG. 5, which is mainly completed in the step), a UML cooperation diagram and a UML activity diagram;

d. And analyzing the thinning sequence of each item and the time-consuming link of the arrangement flow of your.

The model verification in step S2 specifically includes the following:

after the domain modeling is completed, the business model function is reversely deduced through the domain model, and whether the current domain model can realize all the business functions is judged; the method is a one-time check on the rationality of the domain model to ensure the completeness of the domain model.

according to the UML state diagram, the UML time sequence diagram and the UML cooperation diagram, the specific function development of the thermal management field is completed, the infrastructure layer, the field layer, the interface layer and the application layer in the thermal management field model are specifically realized, meanwhile, according to the business condition, the corresponding extension layer is set, and the extension is reserved in advance to prepare for the future; managing the development process, namely outputting a product of each stage corresponding to each stage according to the agile development management model; the code and the corresponding development manual are finally output in the process, and partial screenshots of the development manual are shown in FIG. 6;

the agile development is carried out in the whole vehicle thermal management development process as follows:

and S3.5, in the process that the agile team finishes the iteration demand pool selected from the plan conference, daily standing conferences need to be carried out, and each conference is controlled within 15 minutes. A daily standing meeting, according to the content of the kanban, everyone speaks and reports to all members on the spot what was done yesterday, what is to be done today, and can also be presented if an unsolved problem is encountered. After each person finishes answering, updating the burnout map;

s3.6, when the iteration demand pool is finished, one iteration is finished; at this time, the iterative review conference is carried out, and the responsible person and the client of the thermal management module product participate; each member of the agile team will demonstrate to them the software product that they have completed (this meeting is important and must not be cancelled);

and S3.7, finally, iteratively reviewing the conference, wherein the conference is carried out in a manner of speaking in turn, and each person speaks, summarizes and discusses the improved places, and puts the improved places into the product requirements of the next iteration.

The step S4 specifically includes the following contents:

the step mainly completes the functional verification, including functional verification, performance verification and safety verification, and the verification is correspondingly issued to a software and hardware platform after being completed; the step can be integrated with a mature ci/cd platform for uniformly managing the testing, issuing and upgrading processes, and the process of testing the functions can be guaranteed to be completed before issuing and upgrading; this process finally outputs the test report and uml configuration map, as in fig. 7.

The step S5 is realized according to domain-driven layering, an extension layer is reserved in advance, and input of a new requirement is completed in advance for the extension layer, but the whole steps need to complete requirement determination, requirement investigation, requirement analysis, domain modeling, model design, service development, and test release in sequence.

The invention unifies the models, ensures the accurate execution and transmission of the requirements, has more detailed module division, ensures more definite division of the whole development work, refers to software development, and utilizes the mature modeling idea to ensure the accuracy of service division and high cohesion and low coupling between service modules; by adopting an efficient development mode, the quality can be ensured under the condition of ensuring the progress, and each module is reasonably divided, so that the whole service is easier in the aspect of expanding and upgrading, and the effect of high cohesion is achieved only by regarding the functions of the modules.

The foregoing shows and describes the general principles, essential features, and advantages of the invention. It will be understood by those skilled in the art that the present invention is not limited to the embodiments described above, and the preferred embodiments of the present invention are described in the above embodiments and the description, and are not intended to limit the present invention. The scope of the invention is defined by the appended claims and equivalents thereof.

Claims

1. A field design method for a software defined automobile service development process is characterized by comprising three parts, namely module division, field modeling and model verification, wherein after requirements are determined, according to a thermal management module business model and function points, the business field is sorted and divided, all field objects in the thermal management field are distinguished, all field models included in a thermal management sub-field are determined, each model is designed in detail, and a summary design document and a UML class diagram are correspondingly output and comprise an association relation.

2. The method for designing the field of the software-defined automotive service development process as claimed in claim 1, wherein the field modeling can be specifically performed according to the following steps:

s2.1, understanding market demands through analysis and research, determining problem domains and service expectations, and classifying the problem domains by combining service views; and completing a corresponding finished automobile heat management assembly diagram through a unified uml language:

s2.2, finding out all entities (carriers bearing thermal management business functions), value objects and attributes in the entities in each component in the thermal management field, and completing uml class diagram design;

specifically, the steps of completing the construction of the thermal management module entity by using a four-color modeling method are as follows:

s2.2.1, determining a time mark type object, namely, a footprint is left in the whole event; these footprints are all time-stamped objects; these objects are the starting points for the modeling (e.g., temperature, pm 2.5);

s2.2.2, and S2.2.1, namely, some entity objects are supplemented, participants of time-scale objects generally have three types, objects, places and objects (such as a temperature sensor and a temperature controller);

s2.2.3, how to join role objects, namely entity objects in S2.2.2, into a specific flow, namely actions of the entities;

s2.2.4, adding some proper description objects, and belonging to an entity;

3. The field design method for the software defined automotive service development process according to claim 2, wherein the steps S2.3 and S2.4 are mainly used for combing the business process through an event storm and determining the business boundary, and specifically comprises the following steps:

s2.4.1, identifying field events, mainly tracing past sound events; for example, the temperature is changed, and the water temperature is changed;

4. The method for field design of a software-defined automotive service development process as claimed in claim 1, wherein said field modeling specifically comprises the following:

on the basis of completing module division, the fullness of each field object of the whole vehicle heat management needs to be completed, and corresponding specific variables, parameters and final operation logics in a class diagram are perfected; the step is closely related to the development process, namely, a domain model is converted into a development model, and a UML class diagram, a UML state diagram, a UML time sequence diagram, a UML collaboration diagram and a UML activity diagram are correspondingly output;

a. defining the goals and tasks of the physical object (e.g. the role of the temperature sensor is to output the temperature value and the state value under abnormal conditions)

5. The field design method for the software-defined automotive service development process as claimed in claim 1, wherein said model verification specifically comprises the following:

after the domain modeling is completed, the business model function is reversely deduced through the domain model, and whether the current domain model can realize all business functions is judged; the method is a one-time check on the rationality of the domain model to ensure the completeness of the domain model.