CN113450194A

CN113450194A - Rail transit vehicle product platform construction method

Info

Publication number: CN113450194A
Application number: CN202110913000.0A
Authority: CN
Inventors: 张海柱; 丁国富; 黎荣; 王建; 何旭; 王晨曦
Original assignee: Southwest Jiaotong University
Current assignee: Southwest Jiaotong University
Priority date: 2020-11-20
Filing date: 2021-08-10
Publication date: 2021-09-28
Anticipated expiration: 2041-08-10
Also published as: CN113450194B

Abstract

The invention relates to a method for constructing a platform of a rail transit vehicle product, which comprises the steps of constructing a modular structure tree of a complex electromechanical product; identifying the complex electromechanical product module type; carrying out simple and systematic design on each module; constructing a main structure of a product; building a product platform positioning rule; constructing a requirement-module mapping rule; the construction module configuration rule is established, so that a rail transit product platform is established, the modularization, the generalization and the pedigree construction of rail transit vehicles are facilitated to be promoted, and the diversified customer requirements can be met at lower cost.

Description

Rail transit vehicle product platform construction method

Technical Field

The invention relates to a method for constructing a complex electromechanical product platform, in particular to a method for constructing a rail transit vehicle product platform.

Background

Due to the complexity of the complex electromechanical products in the aspects of requirements, structures, technologies, manufacturing, management and the like, the complex electromechanical products have the disadvantages of multiple product design parameters and constraints, variable design results, long customized production period, high risk and high cost. When the complex product is designed, the reliability of the complex product design can be improved only by fully utilizing the existing mature technology and parts, and the expected design effect is achieved. The importance of establishing a product platform for complex electromechanical products is therefore more prominent than for simple products.

The development of national economy is closely related to transportation. Compared with the transportation modes such as highway, aviation, water transportation and the like, the rail transit has the comprehensive advantages of large conveying capacity, high speed, high safety, high punctual rate, low energy consumption and all-weather operation, and plays increasingly prominent roles in a transportation system. In recent years, the rail transit vehicles in China break through the technical monopoly of Europe and Japan from the dead and followers to the runners, and a series of remarkable development achievements are obtained, and the rail transit vehicle equipment and the industrialization level generally reach the international leading level. Meanwhile, under the background that the economic society is increasingly developed, the traffic transportation demand is increasingly vigorous, and the scale of a road network and the passenger transport capacity are continuously increased, along with the deepening of engineering research, the expansion and the refinement of the market, the accumulation of application data, the development of the demand of pedigree of the rail transit vehicle and the like is promoted, and the rail transit vehicle development faces new opportunities and challenges. The rail transit vehicle is a complex electromechanical product, and a product platform of the rail transit vehicle is inevitably required to be established, so that diversified customer requirements are met at low cost, and the modular, generalized and pedigree construction of the rail transit vehicle is promoted. Therefore, a method for constructing a platform of a complex electromechanical product is urgently needed at present, and more particularly, a method for constructing a platform of a rail transit vehicle product is related.

Disclosure of Invention

The invention aims to: aiming at the requirements of modularization, generalization and pedigree construction of the existing rail transit vehicle, a construction method for a complex electromechanical product platform is provided, and more particularly, the construction method relates to a rail transit vehicle product platform.

In order to achieve the purpose, the invention provides a method for constructing a rail transit vehicle product platform, which is characterized by comprising the following steps of:

step 1: constructing a modular structure tree of a complex electromechanical product; the method comprises the steps that a modular structure tree of the complex electromechanical product, particularly a rail transit vehicle product, is constructed through a multi-level module division method, and a foundation is laid for realizing product platform information management with a module as a carrier through constructing a unified and standard modular structure tree;

step 2: identifying the complex electromechanical product module type; identifying the module types as a platform module and a non-platform module according to the modular structure tree in the step1, wherein the platform module of the product comprises a basic module, a general module and a special module; the identification result is used for module entity design and is used for constructing a product main structure to realize the product customized design driven by the requirement;

and step 3: based on the result of the module type identification in the step2, carrying out simple and systematic design on each module so as to reduce unnecessary and worthless difference;

and 4, step 4: constructing a product main structure, and comprehensively forming the product main structure according to the modular structure tree, the module type identification result and the module entity design result;

and 5: according to the market segment variables and the product platform planning result during the product platform planning, a positioning rule of the product platform is constructed, so that a customer order can be quickly positioned in a certain product platform range during the new order product design, and the customized design is further carried out based on the product platform;

step 6: constructing a requirement-module mapping rule; the method supports the rapid conversion from the requirements of a new order in the customized design based on the product platform to the module attribute parameters by constructing the mapping relation between the customer requirements and the product module attribute parameters under different product platforms;

and 7: constructing a module configuration rule; by constructing the constraint relation among different modules in the main structure of the product, a module configuration rule table of the main structure of each product is formed, and the rationality of module combination during module configuration is ensured.

Compared with the prior art, the invention has the beneficial effects that: compared with the traditional complex electromechanical product platform construction, the method can help enterprises identify the module type and develop simple and systematic design based on the indexes, so that the subjectivity of the product platform construction is effectively reduced, and the product platform positioning rule, the demand-module mapping rule and the module configuration rule are constructed, so that the enterprises can realize the rapid customized design of the product based on the rules, and the research and development efficiency and quality of the enterprises are effectively improved.

Description of the drawings:

FIG. 1 is a modular structure tree construction process for rail transit vehicles;

FIG. 2 is a method of partitioning a plurality of hierarchical modules based on a manifest;

FIG. 3 is a functional-structural breakdown tree of the train information control system;

FIG. 4 is a simplified design of a platform module;

FIG. 5 is a non-platform module (classification summary example) design process;

FIG. 6 is a non-platform module (base template) design process.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be described clearly and completely with reference to the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present invention, and not all embodiments.

Thus, the following detailed description of the embodiments of the invention is not intended to limit the scope of the invention as claimed, but is merely representative of some embodiments of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

It should be noted that the embodiments of the present invention and the features and technical solutions thereof may be combined with each other without conflict.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

The construction method of the complex electromechanical product platform provided by the invention mainly comprises the following steps:

step 1: constructing a modular structure tree of a complex electromechanical product; taking a rail transit vehicle as an example, a modular structure tree of the rail transit vehicle is constructed by utilizing a multi-level module division method. The process for building a modular structure tree for rail transit vehicles as shown in fig. 1 mainly comprises the following four steps:

step1. product example List finishing

For example, the existing product example lists of enterprises are collected according to five product categories of motor train units, urban rail vehicles, locomotives, passenger vehicles and truck vehicles, such as motor train units including CRH1, CRH2, CRH3, CRH380, CR series and the like. And listing the product example lists of various vehicle types, determining the base type products of the various vehicle types, and then preferentially performing module division on the base type products of the various vehicle types.

Step2. Modular Meta-Structure Tree construction

And extracting product list examples of various vehicle types, and then obtaining the modular meta-structure trees of the various vehicle types through module division. The module division is the core of the element structure tree construction, wherein the invention provides a multi-level module division method based on a list, which is shown in the attached figure 2 and mainly comprises system level module division and component level module division. For system-level module division in the method, the method mainly comprises the following three steps: 1) processing a product BOM; 2) judging whether the nodes are divided again or not based on the system scoring table; 3) functional-structural analysis;

the BOM processing of the product mainly comprises two parts, wherein one part is used for classifying the structural nodes and comprises 5 types of standard parts, outsourcing parts, general parts, virtual parts/actual parts and mounting seats. The virtual part refers to a group of virtual parts set which is fictitious by enterprises for management convenience and does not have design and processing drawings, such as roof equipment, vehicle-mounted equipment and the like. And secondly, removing the standard part. In order to improve the efficiency of module division, standard parts such as bolts, spacers, etc. may be eliminated.

And after the BOM processing of the product is finished, judging whether the nodes are divided again or not by traversing the system level nodes and based on the system grade table. And if the total score is more than or equal to 3, suggesting that the nodes are not divided again, and the nodes can be used as a system level module and enter the next level of division. In the system level scoring table, the main consideration of the system level-oriented module division is functional independence, and the system level module preferably only responds to 1 explicit function. For example, the node of the 'car body and built-in equipment' is obviously more than a definite function and is also a virtual part, so that the node needs to be further divided into two system modules of 'car body' and 'in-car facility'. The bogie node has a definite overall function of walking and is not a virtual part, so that the bogie can be directly used as a system-level module without being divided.

Subsequently, as shown in fig. 2, for a system level node with multiple functions, a function-structure analysis is required to divide it into system level modules responding to a clear function (preferably 1). For example, the aforementioned "car body and built-in equipment" node needs to be divided into two system level modules of "car body" and "in-car facility" with definite functions through function-structure analysis. The function-structure analysis may be performed in dependence on a function-structure parse tree, and the present invention provides, for example, a schematic diagram of a function-structure parse tree according to a train information control system, as shown in fig. 3.

As shown in fig. 2, after system level module division is completed, component level module division is required. For the division of the part-level modules, the method mainly comprises the steps of 1) judging whether nodes are divided again or not based on a part scoring table; 2) and (5) performing relevance clustering analysis.

Similar to the system scoring table, the score of each part node is evaluated by adopting the part scoring table, if the total score is more than or equal to 3, the node is not recommended to be divided again and can be used as a part module, otherwise, the node is required to be divided again.

Subsequently, as shown in FIG. 2, a relevance cluster analysis repartitioning module may be employed for component nodes requiring further module partitioning.

Here, module division is a key for building the modular meta-structure tree, and directly influences the construction of a product platform. Aiming at the characteristics of complex structure and layering of rail transit vehicles, the invention adopts a BOM-based multi-level module division method. No matter the system level or component level oriented structure node, the following principles should be followed in the module division process:

1. dividing order

Integral first and local second, primary first and secondary second, functional first and structural second. Firstly, dividing a whole module into a whole module and a local module, namely, firstly, dividing a system-level module into a thinner sub-module, a sub-module and the like according to a certain system module until the last module which can not be subdivided again; firstly, dividing a core module which has decisive significance on product functions, then dividing other secondary modules and finally the auxiliary modules; firstly, dividing the sub-modules according to the structure after the function, namely under the condition that the functional modules are clear;

2. functional independence

The divided modules should be able to independently perform certain functions and try to make one module respond to only one function.

3. Structural independence

The relevance of parts in the modules should be increased as much as possible, the relevance among the modules is reduced, the modules have relative independence, and the independent requirements of module design, management and production are met.

4. Moderate granularity

The module division should satisfy the principle of moderate granularity and quantity. There are 4 instructive opinions as follows:

as many components as possible as modules;

outsourcing pieces are generally not divided;

the mounting seats are generally not subdivided;

general parts are not divided anymore;

step3. Module name dictionary construction

And obtaining the modular meta-structure trees of various vehicle types based on the modular meta-structure tree method constructed in Step2. In order to standardize the product platform and expand subsequent product platforms, module names of modular meta-structure trees of various vehicle types are contrastively analyzed, and meanwhile, a unified and standardized rail transit vehicle module name dictionary can be constructed on the basis of a railway vehicle naming rule and the like. And after the building of the module name dictionary is completed, updating the names of the modular meta-structure trees of various vehicle types.

Step4. Modular example Structure Tree construction

Based on the modularized meta-structure tree obtained at Step2 and the module name dictionary obtained at Step3, modularized example structure trees of five products, namely motor train units, urban rail vehicles, locomotives, passenger vehicles and freight cars with normalized names are obtained through comparative analysis.

The product structure modules are divided through the steps 1-Step4, and a uniform and standard modular structure tree is constructed to lay a foundation for realizing the product platform information management with the modules as carriers.

Step 2: identifying the complex electromechanical product module type; similarly, in the present invention, taking rail transit vehicles as an example, according to the modular structure tree constructed in the step1, "leaf nodes" (non-subdivided nodes) on the modular structure tree are identified as platform modules and non-platform modules, and the product platform modules include a basic module, a general module and a special module; wherein the basic module is a module which is adopted by all products in a product family and has the same shape and characteristics in the products; the universal module is a module which is adopted by a plurality of products in a product family, and the shapes and the characteristics of the universal module are completely the same in the products; the special modules are modules which are adopted by a few products in a product family, and the shapes and the characteristics of the special modules are completely the same in the products; the non-flat modules refer to modules whose shape and characteristics are not exactly the same in a product family. The above identified results will be used for modular entity design, and further build product master structures to achieve demand driven product custom design.

In the identification process, the invention adopts two indexes of 'module similarity' and 'module use degree' for identification. The module similarity refers to the similarity of different module instances of the same module in the aspects of performance, size, interface and the like; the "module usage degree" refers to the frequency of usage of the module in the existing product example. For the "module similarity", the similarity between any two module instances under the same module can be obtained by calculating an average value of the similarities, and the similarity between two module instances can be obtained by calculating an average value of the technical parameter similarities of the two module instances. For the 'module use degree', the use degree of the module can be obtained by counting the frequency of using the module in the existing product example and calculating the use frequency of the module.

The type of the module can be automatically and dynamically identified through the module similarity and the module use degree, and the preset rule is as follows:

if { module similarity is not less than epsilon and module use degree is 1}, then { module is a basic module };

if { module similarity is more than or equal to epsilon and lambda is less than or equal to module use degree <1}, then { module is a universal module };

if { module similarity is more than or equal to epsilon and 0 and is less than or equal to module use degree < lambda }, then { module is a special module };

if {0 ≦ module similarity < ε }, then { module ═ non-platform module };

wherein epsilon and lambda are respectively a similarity threshold and a usage threshold of the module. In general, ε and λ may be set to 0.7 and 0.3, respectively.

And step 3: based on the result of the module type identification in the step2, carrying out simple and systematic design on each module so as to reduce unnecessary and worthless difference; the module simple design comprises a simple design of a platform module and a simple design of a non-platform module.

The platform module is a module with the same shape and characteristics in a product family, and has only one simple example. The simple design process of the platform module is shown in fig. 4, and mainly comprises the following four steps:

step1. defining a required space of a module

Demand space refers to the range of customer demands within a target market, and may be determined based on existing module demands within the market, current customer preferences, technological development trends, and the like. Optionally, the historical bidding technical conditions of the target market can be sorted, the requirements of the modules in the technical conditions can be combed, and the requirement space of the modules can be defined.

Step2. existing Module instance information analysis

And (4) arranging the existing module examples in the target market, carding drawings, models and technical parameters of the module examples, and calculating the information of the module examples, such as the difference degree, the use degree, the reliability, the grade of suppliers, the cost and the like. Illustratively, the present invention provides a calculation method of the above parameters:

1. degree of difference of module instance

Module instance variation refers to the degree to which a module instance varies in all instance sets relative to other instances. The higher the difference value of the module example, the more specific the structural style, shape, material, etc. of the module example, the higher the design, manufacturing and operation and maintenance costs may be, so the module example with the low difference should be selected as much as possible when the example simplification is performed. The module instance degree of difference may be calculated based on equation 6.

In the formula, V_MiIs the degree of variance of module instance i; n is the total number of module instances; v_Mi(i, j) is the degree of difference between module instance i and jth instance, which can be obtained based on equation 7:

in the formula, r refers to the technical parameter attribute of the module instance i, and the total number of the technical parameter attribute is k; the similarity between the module instance i and the jth instance about the r-th attribute is denoted by the similarity, and the similarity is calculated by referring to the formula 4 and the formula 5.

2. Degree of use of module instance

The module instance usage concept is consistent with the module usage concept described above, which reflects the frequency with which module instances are employed by product instances. The higher the usage value of the module instance is, the more widely the module instance is used, so that an enterprise should select the module instance with the high usage as much as possible when performing instance simplification. The degree of usage of the module instance may be calculated based on equation 8.

In the formula of U_MiIs the degree of usage of module instance i; m is the total number of product instances, calculated in units of "vehicles" (e.g., MP1, TC1 vehicles).

3. Module instance reliability

Reliability refers to the ability or likelihood of a module to perform a specified function within a certain time and under certain conditions without failure, and the reliability of the module can be evaluated by averaging the time between failures, etc. Mean Time Between failures (mtbf), i.e., mean Time Between failures, refers to the average operating Time Between two adjacent failures. When the failure rate function follows an exponential distribution, it can be calculated based on equation 9.

In the formula, MTBF_MiMean time between failures, Tlf, for module instance i_iService life of module i, nf_iIs the number of failures of module i during its lifetime.

The larger the MTBF of a module instance, the more reliable the module instance is, and therefore, a module instance with a high MTBF should be selected as much as possible when performing the instance summary design. To facilitate comparative analysis of the MTBF of the module instances, after the MTBF of each instance is calculated, the MTBF of the module instances may be normalized to [0,1] using a maximum normalization method.

4. Module instance vendor scoring

Supplier score refers to the total score that rates a supplier in terms of cooperation and quality assurance, logistics and finance, development and manufacturing capabilities. The higher the supplier score of the module example, the better the quality of the example is guaranteed, so the module example with the high supplier score should be selected as much as possible when the example is designed in a simple system. Illustratively, the scoring detail and calculation method of the suppliers used in the present invention are shown in the following table.

5. Cost of module instance

Module instance costs include supply costs, manufacturing costs, and operation and maintenance costs. Generally, the lower the cost of a module instance, the higher the economic benefit to the enterprise, given its guaranteed quality. In the case of a simple design of the modules, the modules of the lower overall cost are therefore selected as far as possible while the quality of the modules is guaranteed. To facilitate a comparative analysis of the cost of the module instances, after the total cost of each instance is calculated, the cost of the module instances can be normalized to [0,1] using a maximum normalization method.

Step3. Module instance decision

Based on the difference degree, the use degree, the reliability (MTBF), the supplier score and the cost of the module example analyzed by Step2, the module example is scored by the organization domain expert, the highest scoring person is a simple system example candidate, and illustratively, the scoring detail and the calculating method of the module example are shown in the following table.

Step4. Module instance checking

After the optimal existing module example is decided through Step3, calculation, check, simulation and test are further needed to judge whether the existing example meets the demand space. If the module instance meets the demand space, the instance is determined as a simplified instance; if the verification result is not satisfied, a module instance needs to be redesigned and checked, and the module instance can be determined as a simplified instance after the checking is successful.

A non-platform module refers to a module whose shape and characteristics are not exactly the same in a product family, which has multiple instances. However, in order to increase the reuse rate of the modules and reduce the difference of worthless, it is still necessary to briefly design the non-platform modules, such as traction motors, gear boxes, brake clamps, etc. Compared with the global simple system of the platform module, the non-platform module is a classification simple system, namely a plurality of serialized examples are designed to meet the requirement of customer diversification, for example, when a subway bogie platform is built, three traction motor examples responding to three speed grades of 80km/h, 100km/h and 120km/h are designed. The simple design of the non-platform module mainly comprises two types of classified simple system example design and basic template design, wherein the classified simple system example design process is shown in figure 5, and the basic template design process is shown in figure 6.

As shown in FIG. 5, the design process of the classified profile instance of the non-platform module is similar to the global profile instance of the platform module, except that the platform module generates only one profile instance, and the non-platform module needs to generate multiple profile instances in response to diverse requirements. Thus, the classification profile example of non-platform modules differs only from the design of platform modules in the first step, which requires planning multiple module series and the required space for each series. The number of the module series is not too large, generally 2-4, and in order to improve the universality of the modules, each series preferably has only one simple example. After the series planning of the non-platform modules is completed, extracting the existing module examples under each planning series, and then, similar to the design of the platform module examples, deciding an optimal module example for each series or re-developing a new example to finally obtain a classification simple system example responding to diversified requirements.

Second, as shown in FIG. 6, the non-platform module has a base template in addition to the classification profile instance. The base template is a parameterizable structural model, and a new module instance responding to customer requirements can be quickly generated by modifying model parameters.

Firstly, sorting historical bidding technical conditions of a target market, combing requirements related to non-platform modules in the technical conditions, and defining requirement spaces of the non-platform modules;

secondly, information such as drawings, models, structural size parameters and the like of the existing non-platform module examples in the target market are sorted;

thirdly, the relations among the technical indexes of the modules, the technical indexes and the module design parameters are analyzed, and a technical index-module design parameter relation network is constructed. The method comprises the steps of defining driving and driven parameter items in a parameter network, defining the value range of parameters and defining the functional relation among the parameters.

And finally, constructing a 3D &2D base model template supporting parametric variant design by using CAD software (such as CATIA, CERO and the like) based on the defined parameter relation network.

And 4, step 4: constructing a main structure of a product; and comprehensively forming a product main structure by using the modular element structure trees, the module type identification results and the module entity design results of various vehicle types. And identifying the category of each module object according to the identification result of the module type based on the modular meta-structure trees of various vehicle types. The module categories that need to be identified have two dimensions: general degree and type selection requirements. The general degree reflects the universality of the module instance used in all products in the product family, namely, the platform module and the non-platform module identified in the step2 specifically include four types: basic module, general module, special module, non-platform module. The type selection requirement reflects the characteristics of whether the module exists in all products in the product family, and the characteristics can be specifically divided into: a basic module (which is the same as the basic module in the platform module) means that the module must exist and the module instance is unique; the optional module means that the module is always present in all products in a product family, and the module example is not unique; the optional module refers to whether the module is available in products in a product family, and is added or deleted according to the requirements of customers. It should be noted that the optional module is not necessarily a platform module, and the optional module may be a general-purpose module, a special-purpose module in the platform module, or a non-platform module (i.e., optional and non-unique). And carrying out category identification on leaf node modules in the structural tree according to the two module category dimensions. And associating the entity design result of each module with the module object on the modular structure tree to serve as a configurable space of the module object. The product master structure template is given as an example as follows:

and a certain type A subway bogie platform main structure:

and 5: a plurality of product platforms are generally planned and constructed for a certain product category (locomotive, passenger car, truck, motor car, subway, monorail car, etc.), in order to support the future customized design based on the product platform, positioning rules of the product platform need to be constructed according to market segment variables and the result of the product platform planning during the product platform planning, so that a customer order can be quickly positioned in a certain product platform range during the new order product design, and the customized design is further performed based on the product platform.

The positioning rules of the product platforms can be conveniently constructed according to the platform range description of each product platform. Illustratively, the platform range of the type a subway product platform is: the positioning rule of the product platform can be constructed by the following steps of (1) vehicle body type a, (80, 100, 120, 140) speed grade, (80, 100, 120, 140) vehicle body material, (aluminum alloy, stainless steel) and (DC 750, 1500) power supply system: if (the type of a vehicle body & & speed grade ∈ {80, 100, 120, 140} & & vehicle body material ∈ { aluminum alloy, stainless steel } & & power supply system ∈ { DC750, DC1500}), then (the product platform belongs to the type a subway product platform). Description templates are given exemplarily with respect to product platform positioning rules as follows:

and A subway product platform positioning rule:

step 6: constructing a requirement-module mapping rule; by constructing the mapping relation between the customer requirements and the product module attribute parameters under different product platforms, the method supports the rapid conversion from the requirements of a new order in the customized design based on the product platform to the module attribute parameters. According to different mapping modes, the mapping of the demand-module attribute can be divided into: direct mapping, function mapping, knowledge mapping. The definition is as follows:

direct mapping: the demand value is directly used as a mapping mode of the value of the module attribute parameter.

And (4) mapping a function: and converting the demand parameters into a mapping mode of module attribute parameters through function operation.

Knowledge mapping: according to design experience, the requirement parameters are converted into the mapping mode of module attribute parameters by using production rules (if < condition >, then < conclusion >).

According to the number of mapping variables, the mapping relationship between the requirements and the module attributes can be divided into: one-to-one mapping, one-to-many mapping, many-to-one mapping, many-to-many mapping.

For the mapping Rule, it can be expressed as Rule (coding, input _ requirement set, requirement category, output _ module attribute parameter set, associated module, mapping type, mapping Rule). And determining the mapping relation category and the specific mapping rule between the demand parameter and the module attribute parameter of a certain vehicle type through analyzing the relation between the demand parameter and the module attribute parameter. When the mapping rule is constructed, the input requirement set is selected from requirement templates of different vehicle types; the output module attribute parameter set is selected from the attribute parameter sets of each module node on the product main structure of the product platform. The requirements-module attribute parameter mapping rule table template is given exemplarily as follows:

and a type a subway product platform requirement-module mapping rule:

The module configuration knowledge describes the constraint relationship between different modules, and for the convenience of analysis, the two module types need to be synthesized to clarify the characteristics of different modules. According to the module types of two dimensions defined in the main structure of the product, the module types comprise: according to the general degree, the system is divided into a basic module, a general module, a special module and a non-platform module; according to the type selection requirement, the method is divided into a basic module, a necessary selection module and an optional module, and the module types of two dimensions are integrated, so that the following results can be obtained:

4 types of modules are obtained by the classification and synthesis, namely a basic module, a mandatory-non-platform module, an optional-platform module and an optional-non-platform module, so that the configuration rules between any two modules can be analyzed. Module nodes of the basic module exist certainly and the examples are unique, the examples of the basic module can be directly selected only after project order products are positioned to a specific product platform, configuration is not needed, and therefore configuration rules corresponding to the modules do not exist. The constraint relationships among the other three types of modules need to be analyzed, and the following table shows the constraint relationships among the modules of different types:

	optional-non-platform module	Selectable platform module	Option-non-platform module
				Optional-non-platform module	1
Selectable platform module	2	4
				Option-non-platform module	3	5	6

1. Mandatory-non-platform Module constraint relationship

Optional-non-platform module means that module nodes exist certainly but module instances are not unique, and a module with configuration design or modified design can be carried out. Two aspects need to be considered: configurable examples of the modules may belong to different categories (namely different implementation principles or different topological structures), for example, axles can be divided into solid axles and hollow axles according to the topological structures, and basic braking devices can be divided into disc-type braking devices, tread braking devices and the like; secondly, according to requirements or constraint relations of other modules, attribute parameters (size, performance, materials, interfaces and the like) of the modules can be configured with different values, for example, the power of the traction motor can be 250kW and 350 kW. Thus, instantiation of this type of module requires configuration from two levels, namely module type configuration and module instance parameter configuration.

The constraint relationship between modules limits the feasibility of different module configuration combinations, which exists at the two configuration levels described above for any two mandatory-non-platform modules. There are three types of possible configuration constraint relationships between mandatory-non-platform modules, and the constraint relationships between different types of modules are shown in the following table (where "module a type-module B parameter" constraint and "module a parameter-module B type" constraint belong to the same class).

Wherein:

the "module A type-module B type" constraint refers to: such constraints express a constraint relationship between the two modules in type selection. For example, a traction motor module and a coupling module in a platform of a motor vehicle product, a traction motor may be selected from a suspension type and a body suspension type, a coupling may be selected from a flexible floating dog coupling and a cardan shaft, and a constraint relationship between the two may be expressed as if (traction motor is suspension type motor), then (coupling is flexible floating dog coupling) and if (traction motor is body suspension type motor), and then (coupling is cardan shaft).

The "module A type-module B parameters" constraint means: such constraints express a constraint relationship between the type of a module and a module parameter. For example if (traction motor power) kW, then (traction motor cooling fan).

The "module a parameters-module B parameters" constraint means: such constraints express a constraint relationship between parameters of the two modules, including dimensions, performance, materials, interface parameters, and the like. For example, the nominal diameter of the coupling shaft hole is equal to the nominal diameter of the output shaft of the traction motor, the allowable coupling rotation speed is larger than the maximum output rotation speed of the traction motor, and the like.

2. Constrained relationship between mandatory-non-platform modules and optional-platform modules

As analyzed in the mandatory-non-platform module, there may be two levels of configuration of the mandatory-non-platform module: module type configuration and module instance parameter configuration. Whereas an alternative-platform module is a module in which a module node may or may not exist and has a unique module instance. Therefore, the configuration of the optional-platform module only has the existence of configuration, and the configuration of the module category and the module instance parameter does not exist. Thus, there are two types of possible configuration constraint relationships between the mandatory-non-platform module and the optional-platform module, and the following table shows the constraint relationships between the mandatory-non-platform module.

Wherein:

the "module a type-module B presence or absence" constraint means: such constraints express a constraint relationship between the selection of the type of one module and the presence or absence of another module. For example, in a platform of a subway product, if (S-web wheel) and then (disc brake).

The constraint of "module a parameters-module B presence or absence" means: such constraints express the constraint relationship of the setting of one module parameter value to the presence or absence of another module.

3. Constrained relationship between mandatory-non-platform modules and optional-non-platform modules

As analyzed between mandatory-non-platform modules, there may be two levels of configuration of mandatory-non-platform modules: module type configuration and module instance parameter configuration. An optional-non-platform module is a module that may or may not exist in a module node, and has multiple module instances, and may be configured or designed in variations. Referring to the mandatory-non-platform module and optional-platform module, optional-non-platform modules may exist in configurations: configuration of existence, module type configuration, and module instance parameter configuration. There are five types of possible configuration constraint relationships between mandatory-non-platform modules and optional-non-platform modules ("module a type-module B parameter" constraint and "module a parameter-module B type" constraint are the same). The various constraints are as follows, the meaning of which has been explained above and will not be described further here. The following table shows the constraint relationship between the mandatory-non-platform module and the optional-non-platform module.

4. Constraint relationships between selectable-platform modules

As analyzed in the alternate-platform module, the configuration of the alternate-platform module only exists with or without configuration, and the configuration of the module class and the module instance parameters does not exist. Optional-there is only one type of possible configuration constraint relationship between platform modules: "whether or not module A exists" or not module B exists "constraint. The following table shows the constraint relationships between the alternative-platform modules.

The constraint of "presence or absence of module a-presence or absence of module B" means: the constraint relationship between the presence or absence of one module and the presence or absence of another module may be embodied as a dependency constraint (which must be present at the same time) or an exclusion constraint (which cannot be present at the same time).

5. Constrained relationship between selectable-platform modules and selectable-non-platform modules

As analyzed in the option-platform module, the configuration of the option-platform module only exists with or without configuration. As analyzed in the optional-non-platform module, the optional-non-platform module may exist in configurations: configuration of existence, module type configuration, and module instance parameter configuration. There are three types of possible configuration constraint relationships between the optional-platform module and the optional-non-platform module. The following are various types of constraints, and the meaning of each type of constraint is explained as shown above, and is not described herein again. The following table shows the constraint relationship between the optional-platform module and the optional-non-platform module.

6. Constraint relationships between optional-non-platform modules

As with the optional-non-platform module analysis, optional-non-platform modules may exist in configurations: configuration of existence, module type configuration, and module instance parameter configuration. The possible configuration constraint relationships between the selectable non-platform modules are of six types (the existence of the module A and the type of the module B as well as the existence of the constraint of the module A and the type of the module B, the existence of the module A and the parameter of the module B as well as the existence of the constraint of the module A and the parameter of the module B, and the constraint of the module A and the parameter of the module B as well as the constraint of the module A and the parameter of the module B belong to the same type). The various constraints are as follows, the meaning of which has been explained above and will not be described further here. The following table shows the constraint relationship between the mandatory-non-platform module and the optional-non-platform module. The following table shows the constraint relationship between the optional-platform module and the optional-non-platform module.

By combining the analysis of the constraint relationship among the modules, the constraint relationship possibly existing among various modules in the main structure of the product of the project is summarized in the following table. The constraint relationships listed in the table take into account all the types of constraint relationships that may exist between the 3 types of modules, and the actual constraint relationships in the main structure of a certain product are a subset of the table. If a plurality of optional types do not exist in a certain optional-non-platform module in the main structure of the product (the types are unique, and the configuration of the module types does not exist), the constraint relation related to the optional-non-platform module type does not exist. If the existence of an optional-platform module is determined by the requirement, the existence of the class constraint relation related to the optional-platform module does not exist. The following table functions: a framework is provided for analysis of module constraint relations in main structures of different products, and various constraint relations can be comprehensively analyzed according to the framework.

As can be seen from the following table, the above constraint relationships can be generalized to six classes when the association with the module object is ignored: the constraint of 'whether the module A exists or not-the module B exists or not', whether the module A exists or not-the module B type 'constraint,' whether the module A exists or not-the module B parameter 'constraint,' the module A type-the module B type 'constraint,' the module A type-the module B parameter 'constraint,' and the module A parameter-the module B parameter 'constraint'. These six types of constraints are abbreviated as: "presence/absence", "presence/absence-type", "presence/absence-parameter", "type-type", "type-parameter", "parameter-parameter" may be used to describe the category of the module configuration rule.

From the role of configuration rules, module configuration rules can be divided into two types: configuration rules for reasoning and configuration rules for constraint checking. The configuration rule for inference can be expressed by a production formula rule (if ()), then (), a functional relationship y ═ f (x), or the like, and when parameters/conditions are input, an output is calculated by rule inference or a function. The configuration rule for constraint checking is generally expressed by a feasible combination pair (referring to a CSP (body suspended motor, cardan shaft) as a feasible combination), a functional relationship f (x, y) is more than or equal to 0, and the like, and after the types or parameter values of the two modules are configured, whether the set types or parameter values meet the constraint is judged through the feasible combination pair or the functional relationship. Therefore, the specific expression of each type of module configuration rule in the above table may have four types: if (), then (), y ═ f (x), feasible combination pairs, f (x, y) ≧ 0.

After the analysis of the configuration rules among the modules is completed, a module configuration rule table can be constructed, which is specifically shown in the following table:

the module configuration rule of a certain type A subway product platform is exemplarily given:

as described above, the invention provides a method for constructing a complex electromechanical product platform, and particularly relates to a method for constructing a rail transit vehicle product platform, which constructs a product main structure through module division, module type identification and module entity design, and constructs a requirement-module mapping rule, a product platform positioning rule and a module configuration rule to support customized design of a product, thereby providing powerful support for modularization, generalization and pedigree of a rail transit vehicle, being beneficial to promoting the product platform construction of the rail transit vehicle, and realizing meeting diversified customer requirements with lower cost.

The above embodiments are only used for illustrating the invention and not for limiting the technical solutions described in the invention, and although the present invention has been described in detail in the present specification with reference to the above embodiments, the present invention is not limited to the above embodiments, and therefore, any modification or equivalent replacement of the present invention is made; all such modifications and variations are intended to be included herein within the scope of this disclosure and the appended claims.

Claims

1. A rail transit vehicle product platform construction method is characterized by comprising the following steps:

step 2: identifying the complex electromechanical product module type; identifying the irreparable nodes on the modular structure tree into platform modules and non-platform modules according to the modular structure tree constructed in the step1, wherein the platform modules comprise basic modules, general modules and special modules; the identified module type result is used for module entity design and is used for constructing a product main structure to realize the product customized design driven by requirements;

2. The method for constructing a rail transit vehicle product platform according to claim 1, wherein the step1 specifically comprises:

1) product example BOM finishing; collecting existing product examples BOMs of enterprises according to five product categories of motor train units, urban rail vehicles, locomotives, passenger vehicles and freight cars; after the product examples of each vehicle type are listed, determining the base type products of each vehicle type, and subsequently preferentially performing module division on the base type products of each vehicle type;

2) constructing a modular element structure tree; extracting BOM examples of products of various vehicle types, performing module division by using a BOM-based multi-level module division method, and then obtaining a modular element structure tree of various vehicle types through module division, wherein the module division comprises system level module division and part level module division;

3) constructing a module name dictionary; according to the modular meta-structure trees of the car types obtained in the step2, comparing and analyzing the module names of the modular meta-structure trees of the car types, and meanwhile, constructing a unified and normative rail transit vehicle module name dictionary based on a rail vehicle naming rule; after the building of the module name dictionary is completed, updating the names of the modular meta-structure trees of various vehicle types;

4) building a modular example structure tree; and according to the constructed modular meta-structure tree and the constructed module name dictionary, obtaining the modular example structure trees of five products of motor train units, urban rail vehicles, locomotives, passenger vehicles and freight cars with standardized names respectively through comparative analysis.

3. The method for constructing a rail transit vehicle product platform according to claim 1, wherein the step2 specifically comprises: identifying the module type as a platform module and a non-platform module according to two indexes of 'module similarity' and 'module use degree'; the module similarity refers to the similarity of different module instances of the same module in terms of performance, size and interface; the "module usage degree" refers to the usage frequency of the module in the existing product example; aiming at the 'module similarity', the similarity between any two module examples under the same module is obtained by calculating the average value of the similarity between the two module examples, and the similarity between the two module examples can be obtained by calculating the average value of the technical parameter similarity between the two module examples; for the 'module usage degree', the usage degree of the module is obtained by counting the frequency of using the module in the existing product example and calculating the usage frequency of the module, and the preset rule is as follows:

if {0 ≦ module similarity < ε }, then { module ═ non-platform module };

wherein epsilon and lambda are respectively a similarity threshold and a use threshold of the module; wherein ε and λ are set to 0.7 and 0.3, respectively.

4. The method for constructing a rail transit vehicle product platform according to claim 1, wherein the step 7 specifically comprises: according to the modules defined in the main structure of the product, analyzing the configuration rules between any two modules to determine the constraint relationship between the modules; constructing a module configuration rule table according to the determined constraint relation between the modules; wherein the constraint relationship comprises: 1) mandatory-constraint relationships between non-platform modules; 2) mandatory-constraint relationship between non-platform modules and optional-platform modules; 3) mandatory-non-platform module and optional-non-platform module constraint relationship; 4) optional-constraint relationships between platform modules; 5) a constraint relationship between the selectable-platform module and the selectable-non-platform module; 6) optional-constraint relationships between non-platform modules.