JP2006085329A - Specification management device for merchandise - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To realize the plurality of types of calculation of a specific functional block configuring merchandise when a plurality of merchandise models whose specifications are different are included in one merchandise brand in the specification management device of merchandise. <P>SOLUTION: A vehicle model(merchandise brand) and a functional block whose number of type should be calculated are inputted (S10, S12), and a first condition storage part is retrieved, and a plurality of configuration specifications specifying the concrete contents of the function block are acquired, and first type candidates are narrowed down according to the condition specification group (S14 to S18). Then, a second condition storage part is retrieved, and interchangeable conditions for treating the plurality of type candidates as interchangeability are acquired, and second type candidates are narrowed down by gathering the interchangeable type candidates (S20 to S24). Also, a third condition storage part is retrieved, and limiting conditions for limiting the combination of the configuration specifications are acquired, and third type candidates are narrowed down by excluding the configuration specifications whose combination does not exist (S26 to S30). <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a product specification management device, and in particular, assuming that a plurality of product types having different specification contents are known for one product type, a specific functional block constituting the product covers all product types. The present invention relates to a product specification management device capable of calculating the number of types of items.

  For example, with respect to one vehicle, management of each component constituting the vehicle is normally performed by a component configuration table. In addition, even for a plurality of vehicles having different specifications, a parts configuration table is created and managed for each vehicle having each specification. In general, even if the vehicle specifications are different, not all parts are different, and common parts are often used from the viewpoint of standardization. That is, parts having the same specifications are used as common parts across a plurality of vehicles. In such a case, creating a parts configuration table independently for each vehicle with different specifications causes duplication of parts management, enormous amounts of data, and management for distinguishing between common parts and non-common parts. Have difficulty.

  In Patent Document 1, for solenoid valves (products) having the same component configuration, in order to avoid duplicating registration of common components, the product and component attributes are associated with attributes representing the features of the products and components, and attribute variations. Registering and managing parts is disclosed. Here, there are environmental temperature and flow rate adjustment as attributes, and high / normal temperature, low temperature and flow rate adjustment attribute variations are indicated as environmental temperature attribute variations. And the solenoid valve which is a product is divided into a plurality of unique products depending on the difference in attributes and attribute variations. In addition, each part constituting the product solenoid valve may have a plurality of parts even with a part name having the same function due to a difference in attribute and attribute variation. Here, the spring A, the packing A, the screw, the valve A, and the packing box are parts of one specification regardless of the attribute and the attribute variation, but the part having the case function uses the material 1 for high temperature. There are two types, A and a case A ′ using a material 2 for room temperature and low temperature.

  A virtual station BOX is used to represent parts having the same function but different specifications, and each part is registered in the station BOX separately for each attribute and attribute variation. In this case, the configuration of the station BOX is the same across all unique products.

  By using such a database, for example, the component configuration of a high-temperature solenoid valve as a unique product is attributed to environmental temperature and attribute variation to high temperature, and the attributes and attribute variation components are searched for each station BOX. All the retrieved parts can be known by configuring them according to the configuration table of the station BOX. Also, if you want to know only the information on the low temperature components among the components that constitute the low temperature solenoid valve as a unique product, set the attribute as the environmental temperature and the attribute variation as the low temperature, and only the attribute and attribute variation for each station BOX. What is necessary is just to search the registered components.

  As described above, the product / part specification management of Patent Document 1 is divided into a plurality of unique products with different specifications, and the components having the same configuration are also specified for the components that have the same function depending on the components. When there are a plurality of parts having different numbers, the registered data is reduced, and an appropriate search can be performed on the registered data using attributes and attribute variations. Therefore, it is possible to perform a wide-ranging information search across all unique products having different specifications using a database with a smaller amount of data than creating, registering and managing individual component configuration tables for each unique product.

JP 2000-48083 A

  In designing a vehicle, when a new vehicle type design plan is made, a plurality of vehicle types are designed and planned within the range of the vehicle type. For example, when next year's sedan is designed and planned as a vehicle model, the position of the steering wheel and the various functional blocks such as the outer mirror are different between the domestic vehicle model and the export vehicle model. In addition, vehicle types that meet various user needs are required, and in some cases, several dozen types of vehicle types are designed and planned for one vehicle type.

  Thus, when many vehicle types with different specifications of several tens of types are designed and planned for one vehicle type, the specifications of the components constituting the vehicle types are diverse. However, since we want to standardize parts as much as possible, it is important to know how many types are there for a particular part across all the vehicle types in a single vehicle type.

  In Patent Document 1, since the contents of all the unique products and the entire contents of each part are first known, it is considered how to reduce the amount of registered data. It is a premise that the contents of are known. Therefore, it is impossible to know the number of types of a specific part only from information for which all vehicle types are known for one vehicle type.

  Traditionally, counting the number of specific types of parts at the stage where the specifications of the vehicle type are determined throughout many vehicle types depends on the experience of the designer, there are individual differences, and sometimes The number of types and the actual number of types are significantly different. The same problem is not limited to the example of the vehicle. In various products, when one product type includes a plurality of product types, it is also necessary to know the number of types of specific functional blocks in the product type. Arise.

  The present invention relates to a product specification management device capable of calculating the number of types over all product types for a specific functional block constituting a product when a plurality of product types having different specifications are included in one product type. Is to provide.

  The product specification management apparatus according to the present invention provides each product with respect to a correspondence relationship between each of a plurality of product types included in one product type of the product and each content of a plurality of configuration specifications that determine the specification content of the product type. Product specification storage means for storing for each model and each component specification, examination condition storage means for storing examination conditions when examining the specific contents of each of the plurality of functional blocks constituting the product kind, and one product type A number of types calculating means for calculating the number of types of a specific functional block for the whole, and the examination condition storage means groups a plurality of configuration specifications that define the specific contents of the functional block for each functional block. Memorizes a group of conditional specifications and compatibility conditions that summarize the options to be treated as equivalent configuration requirements when there are multiple options in the configuration specification for each configuration specification. The number-of-types calculation means searches the examination condition storage means using the specific function block as a search key, specifies the condition specification group of the specific function block, and sets the specified condition specification group for each configuration specification. Using the means for reading the compatibility conditions and each product type as a search key, the product specification storage means is searched to sequentially read each product type, and then between the read product types, the specified condition specification group Comparing the contents of each configuration specification including compatibility conditions in the range, distinguishing functional block types that have at least one condition specification group with at least one content of each configuration specification including compatibility conditions, and types distinguished from each other Means for obtaining a number, and the obtained number of types is defined as the number of types of specific functional blocks for one entire product type.

  Further, in the product specification management apparatus according to the present invention, the examination condition storage means further stores a restriction condition that is determined for each product type and limits the combination for a combination between a plurality of configuration specifications, The number-of-types calculation means further searches the examination condition storage means using a specific product type as a search key, obtains a restriction condition for the product kind, and the contents of each functional block for the entire product kind And means for narrowing down the number of types to only those in which combinations can exist, except for types for which combinations are limited.

  The examination condition storage means preferably takes over data other than the product condition restriction condition data for the new product type.

  When there are multiple product types in one product type, the number of specific functional blocks that make up the product type can be determined by narrowing down under the conditions related to the number of types. Can be calculated.

  With the above configuration, the contents of the configuration specifications for each of a plurality of product types in one product type are stored in the product specification storage means, and the contents of the examination conditions of the configuration specifications regarding the number of types of each functional block are stored in the examination condition storage means. Remember. Then, narrowing down is performed by applying a study condition for a specific functional block among all product types. Specific processing is performed using a computer.

  That is, a specific functional block for which the number of types is desired is designated, and using this as a search key, the examination condition storage unit is searched, and related constituent specification groups are read. Then, all the product types are read from the product specification storage means, and the contents of the constituent specifications included in the related constituent specification group obtained earlier are compared with each other. If they have the same content, they are grouped as functional blocks of the same type, and the number of types is reduced here.

  Next, the compatibility conditions stored in the examination condition storage unit are used. The compatibility condition is a list of conditions that are actually treated as equivalent configuration specifications even when the names are different when there are a plurality of options for a specific configuration, by listing or the like. Therefore, it seems to be a different type because the names of the options are different, but compared with the compatibility condition, if the compatibility condition is satisfied, it is grouped as the same functional block, and the number of types is further reduced here .

  In addition, the restriction condition for the combination between the plurality of configuration specifications is also stored in the examination condition storage unit, and the number of types calculation unit reads this, for example, compares it with the content of the already narrowed function block Further narrow down the number of types that can exist.

  In addition, for new product types, data other than the product type restriction condition data is taken over to constitute the new product type examination condition storage means, so the restriction conditions may be newly created for the product type. Other examination condition data can be used, and the number of types of specific functional blocks of the new product type can be quickly obtained.

  As described above, according to the product specification management device of the present invention, when a plurality of product types having different specifications are included in one product type, all product types are specified for a specific functional block constituting the product. The number of types can be calculated.

  Embodiments according to the present invention will be described below in detail with reference to the drawings. Hereinafter, vehicle specification management will be described as product specification management, and an example of calculating the number of types of outer mirrors as an example of functional blocks when one vehicle type includes a plurality of vehicle types will be described. The functional block may be a block other than the outer mirror, or a functional block constituting the vehicle, such as an engine or a transmission. The product is not limited to a vehicle, and may be a product including a plurality of product types having different specifications in one product type.

  In the following description, specification management for one vehicle type will be mainly described. As described above, one vehicle specification management device can be assigned to one vehicle type. The specification management device can manage vehicle specifications for a plurality of vehicle types. In addition, the vehicle specification management device may be an independent device, or may be connected to another vehicle specification management device or another device through a network. The vehicle specification management program may be an independent program or may be incorporated into an existing management program.

  FIG. 1 is a block diagram of the vehicle specification management apparatus 10. The vehicle specification management device 10 includes a CPU 12 and an input unit 14 such as a keyboard, an output unit 16 such as a display and a plotter, a vehicle type specification storage unit 18 that stores the specification contents of each vehicle type included in one vehicle type, and a vehicle The review condition storage means 20 for storing the review conditions for the functional blocks constituting the function block is included, and these are connected to each other via an internal bus. The examination condition storage means 20 has an examination condition storage unit 32 for each vehicle type therein. Moreover, you may have a communication control function connected to an external network. The vehicle specification management apparatus 10 can be configured by a computer or the like suitable for data management.

  The CPU 12 includes a number-of-types calculation unit 22 that calculates the number of types of specific functional blocks over one vehicle type including a plurality of vehicle types. The number-of-types calculation unit 22 uses the study conditions stored in the study condition storage unit 32 to narrow down the number of types of specific functional blocks by the first refinement module 24, the second refinement module 26, and the third refinement module 28. Have The CPU 12 also has a data transfer unit 30 that performs data transfer when forming the examination condition storage unit 32 for a new vehicle type. These functions can be realized by software, specifically, by executing a corresponding vehicle specification management program. Moreover, you may comprise so that a part of each function may be implement | achieved by hardware.

  The vehicle type specification storage unit 18 is a storage device that stores the contents of the configuration specifications that determine the specification content for each of the plurality of vehicle types included in one vehicle type. Here, the vehicle type corresponds to a vehicle model. If this is a model called “alpha beta 2000”, the vehicle type means each sub-model in the “alpha beta 2000” series. For example, if the vehicle specifications differ between “Alpha Beta 2000” for the US and “Alpha Beta 2000” for Australia, these are treated as different vehicle types. Various contents for conforming to the USA and Canada are specifications, and the specific specifications are the contents of the configuration specifications. Moreover, a functional block is a block divided according to the function which comprises a vehicle.

  Specifically, an example of vehicle specification data is shown in FIG. The vehicle specification data 40 in FIG. 2 is data indicating the configuration specifications of each of the six vehicle types constituting the “vehicle type 11111” for each vehicle type. The vehicle specification data 40 is in the form of a table, and each vehicle model (42) is arranged in the vertical direction, and each structural specification (44) is arranged in the horizontal direction.

  In the example of FIG. 2, six vehicle types, “111111L-BBBBA”, “111112L-BBBBBK”, “111113R-BBBBW”, “111114R-BBBB”, “111115R-BBBB”, “111116R-BBBB” are shown. Yes. In this vehicle model notation, the first five digits indicate the vehicle type, and the sixth digit is the vehicle type identification. Therefore, the six vehicle types 111111 to 111116 are included in the vehicle type 11111. Although the vehicle type can be specified by this 6-digit notation (46), a handle identifier 48 indicating the distinction of the handle and a destination identifier 50 indicating the distinction of the destination are added for easier identification. The The handle identifier 48 is distinguished by R for the right handle specification and L for the left handle specification. The destination identifiers are distinguished by destination symbols. In the example of FIG. 2, four types of “A”, “K”, “W”, and no symbol are represented. Each shows an American specification, a Canadian specification, a European specification, and a general specification.

  Taking “111113R-BBBBBW” as an example, this indicates that it is the “third” vehicle type of “vehicle type 11111”, the “right steering wheel specification”, and the “European specification” vehicle type. ing.

  The configuration specification 44 is a plurality of specifications determined by configuring the specification content of the vehicle. In the example of FIG. 2, the mirror drive specification and the engine specification are represented. There are many other configuration specifications such as transmission specifications, but they are omitted in the following description. One configuration specification usually has a plurality of options. For example, there are “electric specification (WC)” and “manual specification (WG)” for mirror drive, and there are other options for the engine such as “A specification” and “B specification”. Accordingly, individual configuration specifications can be classified as major classifications, and options in one configuration specification can be referred to as minor classifications.

  As described above, the vehicle specification data 40 is data indicating the content of which option of the small classification is used for each configuration type of the large classification for each vehicle type. As described above, since the vehicle model notation includes the handle identifier 48 and the destination identifier 50, the vehicle specification data 40 includes the contents of the handle specification options and the destination specification options. All of the configuration specifications including the handle specification and the destination specification can be referred to as a broad configuration specification. In the above example of “111113R-BBBBW”, “mirror drive” is “manual specification (WG)” and “engine” is “A specification” in addition to “right handle specification” and “European specification”. Recognize.

  The vehicle specification data 40 is stored in the vehicle type specification storage unit 18 so as to be associated with each vehicle type (42) and each configuration specification (44), that is, to be able to be searched using these as search keys. As the vehicle type specification storage unit 18, a magnetic storage device, a semiconductor storage device, or the like can be used.

  Returning to FIG. 1 again, the study condition storage unit 32 is a storage device having a function of storing the contents of the configuration specifications necessary for studying the design and the like of each functional block for a plurality of functional blocks constituting the vehicle. . There are various conditions necessary for this examination. In FIG. 1, these are arranged as a condition specification group data file 34, a compatibility condition data file 36, and a restriction condition data file 38.

  The condition specification group condition is a group of configuration specifications to be considered when considering the design of a specific functional block and the like, and each configuration specification in this group is used as a condition for review. FIG. 3 is a diagram illustrating an example of the condition specification group data file 34. The condition specification group data file 34 is in a table format, in which all the functional blocks (54) constituting the vehicle such as “outer mirror” are arranged in the vertical direction, and in the horizontal direction, the handle identifier, the destination All of the broad configuration specifications (56) including the identifier are arranged. For a specific functional block, a configuration mark that needs to be examined is marked with a circle as a corresponding mark. Applicable marks are not attached to configuration specifications that do not require examination. As shown in FIG. 3, each functional block is given a unique number as an identification number. In this example, the unique number of the outer mirror is 001111. The unique number can be used as a search key for each functional block.

  In the example of FIG. 3, for the functional block “outer mirror”, “handle”, “destination”, and “mirror drive” are configuration specifications that need to be considered when considering design and the like. Is a condition specification group of the outer mirror.

  As described above, the data of the condition specification group is data indicating a group of a plurality of configuration specifications to be examined in design or the like for each functional block constituting the vehicle. Therefore, whether or not the contents of the functional blocks are the same, that is, whether or not they are the same type of functional blocks, can be seen from the configuration specifications of this conditional specification group. The first narrowing down when calculating the number of types of functional blocks It becomes a condition. The data of the condition specification group is associated with each functional block (54) and each component specification (56) in a broad sense, that is, the condition specification group data in the examination condition storage unit 32 so that these can be searched as search keys. Stored in file 34. Since other examination condition data is also stored in the examination condition storage unit 32, the condition specification group data file 34 can also be referred to as a first condition storage unit.

  The compatibility condition is a condition that is handled as an equivalent configuration specification in each option when there are a plurality of options in the configuration specification. The configuration specification is a configuration specification in a broad sense. Examples of a plurality of options include the electric specification (WC) and the manual specification (WG) in the mirror drive specification, and the A specification and the B specification in the engine specification, as described in FIG. If the configuration specifications are broadly defined, there are right handle specifications (R) and left handle specifications (L) as handle specifications. The destination specifications are American specifications (A), Canadian specifications (K), Australian specifications (Q ), General specifications (no symbol), etc. Among these plural options, the specification name, that is, the case where the actual specification content is the same even though the small classification is different in FIG. 1 is the compatibility state, and the condition is the compatibility condition.

  FIG. 4 is a diagram illustrating an example of the compatibility condition data file 36. The compatibility condition data file 36 is composed of a set of sheets for each structural specification in a broad sense. Sheets are provided for all configuration specifications. In the example of FIG. 4, seats for “handle”, “destination”, “mirror drive”, and “engine” are shown. Each configuration specification sheet includes configuration specification name data 68 and an enumeration table 70 of all options of the configuration specification. In the enumeration table 70, each option is arranged, and in order to indicate a compatibility condition, different independent identification numbers are assigned to independent alternatives, and the same identification numbers are assigned to compatible options.

  In the example of FIG. 4, the handle and mirror drive are incompatible with each other, and are given different identification numbers. For example, “1” is attached to the right handle and “2” is attached to the left handle, which indicates that these are incompatible. On the other hand, there are a total of six options for the destination, among which “no symbol” and “W” are both “1” and are compatible. Similarly, “A” and “K” are both “2” and are compatible. After all, there are 6 types of destination specifications, but there are 4 types of actual contents.

  FIG. 5 shows an example in which the destination sheet 62 of FIG. As you can see, there are four actual contents considering the compatibility conditions of the destination specifications: “1 standard”, “2 English”, “3 plane mirror (Australia)”, “4 Arabic”. “No symbol” = “W”, “A” = “K”.

  As described above, the compatibility condition data is a list of a plurality of choices of configuration specifications and data of the compatibility conditions handled as equivalent configuration specifications among the plurality of options. Therefore, among the different types of functional blocks in the first narrowing-down conditions of the condition specification group, whether or not they are the same type for further compatibility can be determined by checking the compatibility conditions. This is the second narrowing condition when calculating the number of types. The compatibility condition data is stored in the compatibility condition data file 36 of the examination condition storage unit 32 so as to be associated with each configuration specification, that is, so that each configuration specification can be searched using the search key. Since the examination condition storage unit 32 includes a first condition storage unit and the like, the compatibility condition data file 36 can also be referred to as a second condition storage unit.

  The condition specification group data and the compatible condition data can be associated and displayed as one data. For example, in the example of FIG. 4, a box 72 is provided as a part of the configuration specification name data 68 in the sheets 60, 62, 64, 66 for each configuration specification. The box 72 is a box in which, when the user inputs a specific function block, a mark is attached as a corresponding mark for the configuration specifications included in the condition specification group data of the specific function block. In the example of FIG. 4, when “outer mirror” is specified as a specific functional block, the “handle”, “destination”, and “mirror drive” boxes 72 included in the condition specification group of the outer mirror are marked with ○ The "Engine" that is not included in the conditional specification group is not marked with a circle. In this way, information on the condition specification group data can be shown superimposed on the compatibility condition data.

  The restriction condition is a condition for restricting a combination among a plurality of configuration specifications in one vehicle type. For example, when using electric specifications (WC) in mirror drive, it may affect the combination with configuration specifications that are closely related to the mirror. In that case, only a specific combination is allowed or a specific combination is allowed. May only be banned. Specific application of the restriction conditions will be described later.

  As described above, the restriction condition data is data indicating conditions for restricting combinations between the configuration specifications for one vehicle type. Therefore, it is determined whether or not there is a type for the restriction condition among the different types of functional blocks according to the first narrowing condition of the condition specification group and the second narrowing condition of the compatibility condition. It is only necessary to look at the limiting conditions, and this is the third narrowing condition when calculating the number of types of functional blocks. The restriction condition data is stored in the restriction condition data file 38 of the examination condition storage unit 32 so as to be associated with the vehicle type, that is, so that each vehicle type can be searched using the search key. Since the examination condition storage unit 32 includes a first condition storage unit, a second condition storage unit, and the like, the restriction condition data file 38 can also be referred to as a third condition storage unit.

  As described above, the examination condition storage unit 32 includes the condition specification group data file 34, the compatibility condition data file 36, and the restriction condition data file 38. Since these may have different contents for each vehicle type, it is preferable that the examination condition storage unit 32 be grouped for each vehicle type. In this case, a new examination condition storage unit 32 is generated every time a new vehicle type is created. Details of this generation procedure will be described later. The set of examination condition storage units 32 for each vehicle type can be configured by the examination condition storage means 20 by a magnetic storage device, a semiconductor storage device, or the like.

  The operation of the vehicle specification management apparatus 10 having such a configuration will be described. First, the operation of calculating the number of types of specific functional blocks will be described, and then the operation of taking over the data contents of the examination condition storage unit when switching to a new vehicle type will be described.

  FIG. 6 is a flowchart of the procedure for calculating the number of types. Here, the calculation of the number of types is to calculate the number of types of specific functional blocks over one vehicle type including a plurality of vehicle types. The calculated number of types is used for predicting a specific design load, preparing production facilities, and the like. In the following, as an example, using the data described in FIG. 2 to FIG. 5 and calculating the number of functional block “outer mirrors” for all six vehicle models of “vehicle type 11111”. explain.

  A user who wants to calculate the number of types starts up a vehicle specification management program, particularly a part of the number of types calculation program, in the vehicle specification management device 10. Then, the model name is input (S10). Specifically, “vehicle type 11111” is input from the input unit 14. The input data is acquired by the CPU 12. Next, a function block name for which the number of types is to be calculated is input (S12). Specifically, the name of the “outer mirror” or the unique number “001111” is input from the input unit 14. The input data is acquired by the CPU 12.

  Next, the first narrowing is performed by the function of the first narrowing module 24 of the CPU 12. The first narrowing is performed in the order of search of the first condition storage unit (S14), acquisition of the condition specification group (S16), and then the first narrowing down for all vehicle types (S18).

  The search (S14) of the first condition storage unit reads the examination condition storage unit 32 of “vehicle type 11111” in the examination condition storage unit 20 using the vehicle type acquired in S10 as a search key, and further acquires the function acquired in S12. Using the block as a search key, the first condition storage unit, that is, the condition specification group data file 34 is searched. Then, the condition specification group with the unique number “001111” is acquired (S16). In the example of FIG. 3, three configuration specification groups “handle”, “destination”, and “mirror drive” are read and acquired as the condition specification group corresponding to the unique number “001111”.

  The first narrowing down (S18) by the all-type search is executed as follows. That is, first, the vehicle type specification storage unit 18 is searched using the vehicle type acquired in S10 as a search key, and all vehicle types included in the “vehicle type 11111” are read. Next, focusing on the configuration specifications of the condition specification group acquired in S16, the read-out all vehicle types are sequentially compared to see if the contents match or do not match. The matching items are collected as the same type as the outer mirror, and are narrowed down to different types.

  FIG. 7A is a diagram illustrating a state of the first narrowing down. This table is arranged with the contents of FIG. 2 narrowed down to three broad configuration specifications of “handle”, “destination” and “mirror drive” which are condition specification groups. That is, since all the vehicle types included in “vehicle type 11111” are 6 vehicle types from the data in the vehicle type specification storage unit of FIG. 1, for each of these 6 vehicle types, “handle”, “destination”, “mirror” Only three configuration specifications “drive” are extracted and arranged. At the stage of arrangement, all vehicle types are searched and arranged, so there are six types of outer mirror type candidates.

  Next, among the six types of outer mirror type candidates, those that match all the contents of the three structural specifications of “handle”, “destination”, and “mirror drive” are collected. In the example of FIG. 7A, three of the type numbers 4 to 6 have the same contents of “handle = R”, “destination = no symbol”, and “mirror drive = WG”. As can be seen from FIG. 2, the vehicle type is different because the content of the structural specification “engine” is different, and is the same in the range of the condition specification group of the outer mirror. Therefore, three of the type numbers 4 to 6 are collected as the same type as the outer mirror. Whether or not the contents of the three configuration specifications are the same can be executed by performing a data comparison determination process. For example, for each vehicle model, the digital data of each configuration specification is sequentially compared between the two vehicle types to determine whether they are the same, and if all the digital data of the three configuration specifications match, the type of outer mirror is selected. If they are the same and even one is different, they are of different types. As a result, the number of types of outer mirrors is narrowed down to four.

  FIG. 7B is a diagram illustrating a state after the initial six outer mirror type candidates are narrowed down to four type candidates. These four types of outer mirrors are recognized as different types within the range of the condition specification group as long as the vehicle specification data.

  Returning to FIG. 6 again, following the first narrowing, the second narrowing is performed by the function of the second narrowing module 26 of the CPU 12. The first narrowing is performed in the order of search of the second condition storage unit (S20), acquisition of compatibility conditions (S22), and then second narrowing (S24).

  The search (S20) of the second condition storage unit searches the second condition storage unit, that is, the compatible condition data file 36 in the examination condition storage means 20, using each configuration specification of the condition specification group acquired in S16 as a search key. . Then, the compatibility conditions are acquired for each configuration specification (S22). In the above example, since the configuration specifications of the condition specification group are “handle”, “destination”, and “mirror drive”, the compatibility conditions for these are respectively read and acquired. Referring to FIG. 4 or FIG. 5, there is no compatibility condition for “handle” and “mirror drive”, and for “destination”, the compatibility conditions are “no symbol” = “W”, “A” = “K”. It is.

  The second narrowing (S24) is performed on the result narrowed down in S18. Specifically, the types of outer mirrors narrowed down in S18 are sequentially compared by applying the compatibility conditions, and whether the contents after application of the compatibility conditions match or not are compared. And what is in agreement is further summarized as being the same type as the outer mirror, and further narrowed down to different types.

  FIGS. 7B and 7C are views showing a state of second narrowing. FIG. 7B shows four types of outer mirrors arranged after the first narrowing down, and shows the configuration specifications separately for each compatibility condition. That is, R and L of the “handle” and WC and WG of “mirror drive” are incompatible, so that “Destination” satisfies the compatibility condition, and “No symbol, W”, It is divided into four items “A, K”, “Q”, and “V”.

  In the narrowing down, in the item classification according to the compatibility condition, the four types of outer mirror type candidates are respectively compared, and the items in which the contents of all items match are collected. In the example of FIG. 7B, the type numbers 1 and 2 are grouped together because the contents of the items match each other. Similarly, the type numbers 3 and 4 are grouped together because the contents of the items match each other. Whether the content of each configuration specification is the same including the compatibility condition can be executed by performing a data comparison determination process. For example, digital data of each configuration specification is rewritten to the same data by applying compatibility conditions and satisfying the compatibility conditions. Then, for each outer mirror type candidate, digital data including compatibility conditions of each configuration specification is sequentially compared between the two types of candidates to determine whether they are the same, and digital data including the compatibility conditions of all configuration specifications is determined. If all the data match, the type of the outer mirror is the same, and if even one is different, the type is different. As a result, the number of types of outer mirrors is narrowed down to two.

  FIG. 7C is a diagram showing a state after the four outer mirror type candidates in FIG. 7B are further narrowed down to two type candidates. These two types of outer mirrors are recognized as different types within the range of the conditional specification group and the compatibility conditions.

  In the above description, the first narrowing and the second narrowing are performed sequentially. However, in practice, the first narrowing and the second narrowing may be performed continuously as one process. For example, as described with reference to FIG. 4, the condition specification group data and the compatibility condition data are associated with each other and collected as one data. When the user inputs “outer mirror”, the “handle” The compatibility condition can be output as it is, with a circle mark as a corresponding mark in the “destination” and “mirror drive” boxes 72. And based on this, the arrangement | sequence data of FIG.7 (b) can be obtained, and it can narrow down to two outer mirror type candidates as shown in FIG.7 (c) by mutual comparison from this.

  Returning again to FIG. 6, steps S <b> 26 to S <b> 30 indicate a procedure in which the third narrowing is performed by the function of the third narrowing module 28 of the CPU 12. The third narrowing is performed in the order of search of the third condition storage unit (S26), acquisition of the limiting conditions (S28), and then the third narrowing (S30).

  In order to make it easier to understand how the restriction conditions are narrowed down, there are many types of vehicles that are different from the vehicle types described in Fig. 2, and there are restrictions on the combination among multiple specifications in the entire vehicle type. Take up. FIG. 8 shows an example of such a car model. Here, there are 35 types of types of outer mirrors, and the configuration specifications are broadly classified into “handle”, “destination”, “mirror drive”, “ ”,“ Kakiku ”, and“ Sasis ”are shown, and under each component specification major category, a minor category including compatibility conditions is shown. As described above, the processing of the processes of S10 to S24 is executed by the function of the CPU 12 as described above, and not only the configuration specifications of the condition specification group for all the narrowed outer mirror type candidates, It can be obtained by arranging at least the configuration specifications related to the limiting conditions.

  FIG. 9 is an example of a limiting condition. Here, “mirror drive WC = satisfaction AU”. The specific content is that the specification is “Sussis AU” when “mirror drive” is electric WC, and conversely, it is other than “Sussis AU” when “mirror drive” is other than electric WC. . In other words, the combination of the “mirror drive” and “Sussis” specifications is conditioned so that there is no other than the combination of (WC, Sasis AU). Such a restriction condition can be acquired by searching the third condition storage unit, that is, the restriction condition data file 38 in the examination condition storage means 20 using the vehicle model acquired in S10 as a search key (S26) (S28). .

  The third narrowing (S30) is performed by comparing the contents of FIG. 8 with the limiting conditions of FIG. Specifically, it is sequentially determined whether or not the restriction condition is applied to each type candidate of 35 types of outer mirrors. Then, according to the limiting conditions, only the existing combinations are left, and the outer mirror type candidates having the non-existing combinations are removed and narrowed down. Whether or not each type of outer mirror candidate has a combination that satisfies the restriction condition can be executed by performing a data comparison determination process. For example, the restriction condition “mirror drive WC = sussis AU” is rewritten to the digital data equation of the configuration specification, and whether each equation is satisfied is determined for each outer mirror type candidate. If the restriction conditional expression is satisfied, the outer mirror type candidate is left as it is, and if it is not satisfied, it is removed from the type candidates.

  In the example of FIG. 9, “mirror drive WC = sussis AU” is the specification of “sussis AU” when “mirror drive” is electric WC, and conversely, when “mirror drive” is other than electric WC, Therefore, there are two types (WC, Sasis AT) of type number 1 and (WG, Sasis AU) of type number 4 that do not satisfy this restriction condition. If these two are excluded from the 35 types of outer mirror type candidates and narrowed down, 33 types of outer mirror types are obtained. FIG. 10 is a diagram showing the outer mirrors thus narrowed down to 33 types.

  In the third narrowing down, when there is a limit on combinations among a plurality of configuration specifications in one entire vehicle type, the second narrowing (( Although it can be performed subsequently to S24), it can also be performed between the first narrowing and the second narrowing. In some cases, it can be performed before the first narrowing. Further, when it is not necessary to perform the third narrowing, this can be omitted.

  Returning to FIG. 6 again, the type output step (S32) is a step of outputting the number of types of specific functional blocks narrowed down by the narrowing step as described above to the output unit 16. It is good also as what outputs the detailed content of each kind collectively. For example, when there are six vehicle types in the example of FIG. 2 and there is no third narrowing down, the list of FIG. 7C or simply two types are displayed and output. Further, when the restriction condition is further narrowed down in the example of FIG. 8, the list of FIG. 10 or simply 33 types are output.

  As described above, when the vehicle type specification storage unit 18 and the examination condition storage unit 32 store the vehicle type of the desired vehicle type, the data of the specification contents, and the examination condition data of the functional block in advance, the above procedure is performed. Thus, the number of types of each functional block can be obtained. Each time a new vehicle type is examined, the contents of the specification management device for many vehicle types are improved by additionally updating the data in the vehicle type specification storage unit 18 and the examination condition storage unit 32 for the vehicle type. Go.

  Next, the takeover action of the data contents of the examination condition storage unit when switching to a new vehicle type will be described. How to make a vehicle model for a new vehicle type is examined at a relatively early planning stage or the like, and therefore, addition and update of data in the vehicle type specification storage unit 18 are performed at an early time. On the other hand, the contents of the examination condition storage unit 32 have many common parts. For example, regarding the outer mirror, the contents of the conditional specification group are basically the same even if the vehicle type changes. In addition, even if the compatibility conditions are changed even if the vehicle type changes, the conventional contents are rarely changed. However, the restriction conditions may vary greatly depending on the vehicle type.

  This is schematically shown in FIG. Here, it is shown how the data of the examination condition storage unit 32B for the new vehicle type B is generated when the data contents of the examination condition storage unit 32A for the vehicle type A are already prepared. . In other words, the new examination condition storage unit 32B is generated by taking over data other than the vehicle type-specific restriction condition data file 38A among the data already stored in the examination type storage unit 32A for a certain vehicle type, and newly creating the vehicle type B. This can be done by creating a restriction condition data file 38B for use and replacing it.

  FIG. 12 is a flowchart showing a procedure of data takeover when data in the examination condition storage unit is newly generated. This procedure is executed by the function of the data takeover unit 30 of the CPU 12 in the vehicle specification management apparatus 10.

  A user who creates a new vehicle type and efficiently generates data in the examination condition storage unit by taking over starts up a vehicle specification management program, particularly a data takeover program part, in the vehicle specification management apparatus 10. Then, the model name is input and set (S40). Then, a new restriction condition for the vehicle type is input (S42). Specifically, necessary data is input from the input unit 14. The input data is acquired by the CPU 12.

  Then, among the data files in the examination condition storage unit for another existing vehicle type, the restriction condition data file is replaced with the one obtained from the input unit 14, and the other data files are taken over as they are, and the new examination condition storage unit Is created (S44). Specifically, old and new data file replacement processing is performed for the restriction condition data file. Since a new configuration specification may be added for a new vehicle type, it is checked whether the configuration specification in the new examination condition storage unit is insufficient (S46). More specifically, the configuration specifications included in the new restriction conditions are compared with the configuration specifications constituting the condition specification group data file and the compatibility condition data file, and a determination is made as to whether or not there is an identical one. If the same configuration specification is not detected, the configuration specification is added (S48). The addition is performed for both the condition specification group data file and the compatibility condition data file. When the same configuration specification is detected and there is no shortage, and when a shortage of the configuration specification is added, generation of a new examination condition storage unit is completed there.

In this way, the data file of the existing examination condition storage unit can be used effectively, and the examination condition storage unit for a new vehicle type can be quickly generated. By using this, the number of types for the desired functional block can be obtained. it can.

1 is a block diagram of a vehicle specification management device in an embodiment according to the present invention. It is a figure which shows the example of the vehicle specification data in embodiment which concerns on this invention. It is a figure which shows the example of the condition specification group data file in embodiment which concerns on this invention. It is a figure which shows the example of the compatibility condition data file in embodiment which concerns on this invention. In embodiment which concerns on this invention, it is an example which shows the destination sheet | seat of FIG. 4 with a sheet | seat of another description. It is a flowchart of the procedure of calculation of the number of types in embodiment which concerns on this invention. It is a figure which shows the mode of narrowing down in embodiment which concerns on this invention. In embodiment which concerns on this invention, in order to demonstrate narrowing-down of a limiting condition, it is a figure which shows the state before narrowing down. It is an example of the limiting conditions in the embodiment according to the present invention. In embodiment which concerns on this invention, it is a figure which shows the state after narrowing down of limiting conditions. In embodiment which concerns on this invention, it is a figure which shows how the data of the examination condition memory | storage part for new vehicle types are produced | generated. 5 is a flowchart showing a procedure of data takeover when data of a new examination condition storage unit is newly generated in the embodiment according to the present invention.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 10 Vehicle specification management apparatus, 12 CPU, 14 input part, 16 output part, 18 vehicle type specification memory | storage part, 20 examination condition memory | storage means, 22 kind number calculation part, 24 1st narrowing down module, 26 2nd narrowing down module, 28 3rd Refinement module, 30 data takeover part, 32, 32A, 32B examination condition storage part, 34 condition specification group data file, 36 compatible condition data file, 38, 38A, 38B restriction condition data file, 40 vehicle specification data, 42 vehicle model, 44, 56 Composition specification, 46 Vehicle model notation, 48 Handle identifier, 50 Destination identifier, 54 Function block, 60, 62, 63, 64, 66 Seat, 68 Composition specification name data, 70 Enumeration table, 72 box.

Claims (3)

Product specifications that are stored for each product type and each component specification about the correspondence between each of a plurality of product types included in one product type of the product and each content of a plurality of component specifications that determine the specification content of the product type Storage means;
An examination condition storage means for storing examination conditions when examining the specific contents of each of the plurality of functional blocks constituting the product type;
The number of types calculating means for calculating the number of types of a specific functional block for one product type,
With
The study condition storage means is
For each functional block, a conditional specification group that groups together multiple configuration specifications that define the specific content of the functional block,
For each configuration specification, when there are multiple options in the configuration specification, compatibility conditions that summarize the options treated as equivalent configuration requirements,
Remember
The number of types calculation means is
Using the specific function block as a search key, search the examination condition storage means, specify the condition specification group of the specific function block, and read out the compatibility condition for each configuration specification constituting the specified condition specification group;
Using each product type as a search key, search the product specification storage means to sequentially read each product type, and then include compatibility conditions within the range of specified condition specification groups between each read product type. Means for comparing the contents of each configuration specification, distinguishing functional block types having at least one condition specification group including at least one content specification condition including compatibility conditions, and obtaining the number of types distinguished from each other;
A product specification management apparatus characterized in that the number of types obtained is the number of types of specific functional blocks for one product type as a whole. In the product specification management device according to claim 1,
The examination condition storage means further includes:
It is determined for each product type, and for combinations between multiple configuration specifications, it stores the restriction conditions that limit the combinations,
The number of types calculation means further includes:
Searching the examination condition storage means using a specific product type as a search key, and obtaining a restriction condition for the product type,
Compare the contents of each functional block with the restriction conditions for the entire product type, remove the types for which combinations are restricted, and narrow down the number of types to those that can have combinations,
A product specification management device characterized by comprising: In the product specification management device according to claim 2,
The study condition storage means is
For new product types, a product specification management device that takes over data other than product type restriction condition data.

Images