WO2004038618A2 - Procede et dispositif pour synthetiser une architecture electrique - Google Patents

Procede et dispositif pour synthetiser une architecture electrique Download PDF

Info

Publication number
WO2004038618A2
WO2004038618A2 PCT/FR2003/003108 FR0303108W WO2004038618A2 WO 2004038618 A2 WO2004038618 A2 WO 2004038618A2 FR 0303108 W FR0303108 W FR 0303108W WO 2004038618 A2 WO2004038618 A2 WO 2004038618A2
Authority
WO
WIPO (PCT)
Prior art keywords
service
data
elementary
computer
screen
Prior art date
Application number
PCT/FR2003/003108
Other languages
English (en)
Other versions
WO2004038618A3 (fr
Inventor
Samuel Boutin
Christophe Dang Van Nhan
Original Assignee
Renault S.A.S.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Renault S.A.S. filed Critical Renault S.A.S.
Priority to AU2003285418A priority Critical patent/AU2003285418A1/en
Priority to US10/532,089 priority patent/US20060229742A1/en
Priority to JP2004546103A priority patent/JP2006504170A/ja
Priority to EP03778417A priority patent/EP1556803A2/fr
Publication of WO2004038618A2 publication Critical patent/WO2004038618A2/fr
Publication of WO2004038618A3 publication Critical patent/WO2004038618A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/18—Network design, e.g. design based on topological or interconnect aspects of utility systems, piping, heating ventilation air conditioning [HVAC] or cabling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0283—Price estimation or determination

Definitions

  • the present invention relates to a method and a device for synthesizing an electrical architecture and the applications of this method to a vehicle, and in particular a method and device for designing a specification of a hardware and software system.
  • the present invention aims to provide an improved method and device for synthesizing an electrical architecture and the applications of this method to a vehicle, and in particular to provide an improved method and device for designing a specification of a system. hardware and software.
  • the present invention relates to a system architecture design tool, characterized in that it comprises several screens which each include:
  • the present invention provides a method for designing a specification of a hardware and software system, characterized in that it comprises: a step for defining services and, for each service, use cases;
  • the design procedure may include the production of a copy of data, such as data which can be read by a machine for the automatic implementation of a step of manufacturing or testing systems, or by a person to control such a system.
  • the services represent services for the benefit of a user of the system, for example the driver of a vehicle on board said system.
  • Services are defined by what the user wants (for example the start of air conditioning, wipers) or by what is offered (for example passive safety, especially in the event of accidents) .
  • They are also defined by sensors and / or actuators which they implement. They each correspond to a sensor / software / actuator hardware implementation, the sensor being able to be hardware (sensors in dashboard or pedals, for example).
  • the design tool makes it possible to determine system specifications, interfaces and what the elements of the system must include and their communication with the other elements of the system.
  • the tool comprises a selection means, called a "tab", of a hierarchical description, the selection of each tab showing a screen different from the tool.
  • the transition from one screen to another is particularly easy.
  • the hierarchical description represents, at a first level of hierarchy, a plurality of services, and at a second level of hierarchy, a plurality of use cases for each service.
  • each service is defined by the cases of its use.
  • the “wipers” service can be defined by use cases of alternating wiping, slow wiping and fast wiping.
  • each use case comprises a context or initial situation of the system, a request from a user to the system and a response from the system corresponding to a change in its state.
  • states and associated state transitions are defined. Thanks to each of these provisions, the use cases are formalized and in direct relation to the situations and states of the system and the requests of the user of the system which define the transitions between states.
  • each state is associated with a phase of the system, all the formalized use cases representing all the responses or absence of response of the system in all the phases, these representing, together, all the combinations of the operating modes of the vehicle. Thanks to these provisions, the states are hierarchized which allows a better readability because we can consider each phase separately, then each phase transition.
  • each phase consists of a set of combinations of vehicle operating modes, the modes being transversal to the services and outside direct control of the services, for example a mode representing a level of available energy and / or a type of system user and or an accident or not condition of a vehicle.
  • the hierarchical description represents, at a first level of hierarchy, a plurality of services, and at a second level of hierarchy, phases of the service.
  • the hierarchical description represents, at a first level of hierarchy, a plurality of services, and at a second level of hierarchy, states.
  • a hierarchical level describes, in a given state, the elementary operations.
  • a user can perform a placement of elementary operations on components represented on a synthetic view. Thanks to these provisions, the functional aspects of the system can be implemented on the hardware components of this system.
  • the tool comprises, for at least one screen, a synthetic view representing an envelope of a component and each elementary operation that said component controls or commands.
  • the user of the tool can study the operation of each component and the specifications resulting therefrom.
  • the tool comprises, for at least one screen, a synthetic view representing an envelope of a service and each elementary operation that said service comprises.
  • the user of the tool can study the operation of each service and the resulting specifications.
  • the hierarchical description represents computers of the system, at a first level of hierarchy, and at a second level of hierarchy, elementary operations controlled or commanded electronically by each computer.
  • the user of the tool can study the operation of each computer and the specifications resulting therefrom.
  • a synthetic view represents, for each computer, the services which are, at least partially, placed on said computer.
  • the user of the tool can study the relationships between the services and the computers.
  • a synthetic view represents, for each computer, the modes in which said computer must operate.
  • the user of the tool can study the relationships between the modes and the computers.
  • a synthetic view represents at least one network and the components connected to it.
  • the hierarchical description represents computers of the system, at a first level of hierarchy, and at a second level of hierarchy, for each computer, the data frames passing over the buses to which is connected the computer and / or electronic components (sensors, actuators) directly connected to the computer. Thanks to these provisions, the tool user can study each computer and the interactions it has with other elements of the system, in particular the buses to which it is connected.
  • the hierarchical description represents frames, at a first level of hierarchy, and at a second level of hierarchy, for each frame, the data contained in the frames.
  • the user of the tool can detail the messaging used and establish the relationships between the frames and the data they contain.
  • a synthetic view represents components and / or networks and a projection of a service on said components and / or networks.
  • a hierarchical level describes, for each elementary operation, the input and output data flows of the interface, for each data flow, the pilot and the component and / or the elementary operation, with which the data stream is exchanged.
  • the user of the tool can study the detail of the implementation of an elementary operation, in terms of data flows, of pilots and / or of components.
  • the hierarchical description represents, at a first level of hierarchy, a plurality of services, and at a second level of hierarchy, a plurality of service variants, for each service. Thanks to these provisions, the tool makes it possible to deal with different variants of a service in the design of the architecture of a system.
  • the hierarchical description represents, at a first level of hierarchy, a plurality of electronic components, and at a second level of hierarchy, a plurality of variants of electronic components, for each electronic component.
  • the tool makes it possible to deal with different variants of a component, for example different components from different equipment manufacturers, in the design of the architecture of a system.
  • a selection, with a pointing device, of an element of the synthetic view gives access to an operating representation of said element. Thanks to these provisions, the user of the tool can study the operation of the various elements represented in the synthetic view.
  • the present invention relates, according to a second aspect, to a method for synthesizing an electrical and electronic architecture of at least part of a product comprising electrical wires and electrical and electronic components such as sensors, actuators and computers, characterized in that it comprises the following stages:
  • a 2-D topology is a result of the method. Also, according to the present invention, the paths are generated automatically. Thanks to these provisions, routing by iteration is optimized.
  • connection point corresponds, in the product, to a connector and / or at least one routing point corresponds, in the product, to a connector.
  • the representation is more faithful and takes into account the size of certain areas of the product.
  • the cabling consisting of the synthesized routing and connectors is displayed. Thanks to these provisions, the placement of the routing points can be perfected by simplifying the geometry of the strands.
  • the method includes a step of validating a routing among those evaluated, and a technical specification of the wiring consisting of validated synthesized routing and of connectors is calculated, and the calculation is carried out following the technical specification, calculating the cost of wiring and / or calculating a quality measure, for example by estimating the number of breakdowns per million and per year of wiring.
  • the product is a vehicle and the different areas of the vehicle include at least one of the following areas:
  • the method can be applied to a motor vehicle.
  • the present invention relates to a system architecture design tool, characterized in that it comprises, for objects, hardware components and / or services offered to the client, a so-called "envelope" graphic representation which comprises : - a contour representing said object,
  • the user of the tool has a synthetic view of the interaction of the object with other objects of the system.
  • said envelope represents a hardware component
  • data representations are made for a service.
  • the present invention relates to a system representation tool comprising electronic components each connected to at least one bus, characterized in that it comprises, for each bus, a representation of the components which therein are directly connected and, for the components directly connected to at least two buses, for each of these buses, associated with said component, an identifier of each other bus to which said component is directly connected.
  • the user of the tool has a three-dimensional view, without complexity of representation, each bus being represented in two dimensions and the links between the buses being represented, according to a third dimension, by means of the identifiers. .
  • said identifier is a graphic element, for example a patch of a color identical to that of the bus in said representation.
  • the present invention relates to a method for designing a specification of a hardware and software system, characterized in that it comprises: - a step of defining services and, for each service, of case use ;
  • this process makes it possible to start from the services offered to the user of the system, to determine the operation of the system then to implement the elementary operations implementing the services on computers and to identify the consequences of the implementation in terms of data flows and / or in terms of interface specification.
  • the placement stage includes, for each service, a choice from several placement methods including in particular: - the placement of the service on a single computer,
  • each service can be carried out on one or more components, with corresponding elementary control operations.
  • the additional elementary operations are generated automatically with:
  • a state of each data stream is determined, with respect to a given messaging system:
  • the data and the frames can be organized, and during the design of the system, it is possible to measure the work remaining to be done to cover all of the data exchanges by the different frames.
  • a performance constraint is expressed on this use case as well as on some of the elementary operations carried out in the arrival state of said use case, the tool synthesizes then automatically the list of executions of elementary operations, executions of pilots, writes and readings in frames, taking into account information by sensors and actuators, frame transfer on a network implemented following placement of said elementary operations and the designer can validate that this performance constraint is satisfied for a placement of said elementary operations or specify execution time and / or response time requirements to satisfy this performance constraint. Thanks to these provisions, it is possible to ensure that the system will have the expected performance and in particular it is possible to develop performance requirements for the various components of the system.
  • said variants have shared elementary operations, then said elementary operations are placed on the same computers or computer variants.
  • vehicle access variants one with key, the other without key, will share the basic locking and unlocking operations.
  • the present invention relates to a tool for designing a wiring plan, characterized in that it comprises several screens which each include: - a hierarchical description of the hardware components to be placed - a two-dimensional representation of the zones on which the components are placed.
  • the two-dimensional representation of the zones on which the components are placed comprises an overall view of all the zones as well as a means of adding or removing zones.
  • a zone is selected in the global view of all the zones, a local view of the zone, local view in which geometric characteristics of the zone can be specified, for example by clicking and dragging contour points of the area, appears.
  • the designer can specify preferential crossing points for routing the wires which will make it possible to form strands, preferential crossing points from one zone to another and avoidance subzones in which no wire can pass for example for mechanical reasons or of obstruction, the places of the zone which can be used as mass.
  • a routing point or a connection point between zones can be transformed into a connector by clicking on an attribute of said routing or connection point.
  • the designer can specify the location where these components will be placed in the different areas of the product. According to particular characteristics, the routing of the various sensors and actuators is automatically synthesized up to the various fuse boxes and relays and electronic control units.
  • each sensor and each actuator data pins associated with pilots (hardware and software) themselves associated with data, power pins corresponding to the power supply and ground pins being specified, the routing of the wires corresponding to these wires is synthesized automatically to the electronic control units or to the fuse boxes and relays for the data, to the relay fuse boxes for the power wires and to the nearest earths respectively.
  • the number of pins of the connectors, of the connectors of the electronic control units and of the fuse and relay boxes is evaluated, as well as the size of the different strands.
  • a sensor or an actuator is connected to a computer in the system architecture design tool, then, during the routing synthesis, the data pins of said sensor or of said actuator are connected to said calculator. Thanks to these provisions, requirements for connecting a sensor or an actuator to a computer, for example for contractual reasons with a supplier, are taken into account in the design of the electrical and electronic architecture. According to particular characteristics,
  • a cost function of the connectors for example based on a chart which gives an estimate of the price of the connectors according to the number of data, power and mass connections, or based for example on an average price assigned to each connection of a data wire, current or ground,
  • the cost estimate is automatic from any placement made in the system architecture design tool of a plurality of services for which estimates have been made.
  • a quality measurement of an electrical and electronic architecture is automatically estimated.
  • the quality of an electrical and electronic architecture is automatically estimated. Thanks to these provisions, it is possible to assess the respective quality of two electrical and electronic architectures.
  • a quality measure is automatically calculated for the execution of an elementary operation, and for the execution of a set of elementary operations on a computer. Thanks to these provisions, the operating quality of the computers is taken into account precisely in the quality evaluation of an electronic electrical architecture.
  • candidate routing points are automatically determined in each zone in order to group the power and mass wires in splices and one automatically chooses the one which minimizes the length of wire in said zone.
  • the length of the wiring is optimized and the size of the connectors is minimized.
  • splices are taken into account in cost and quality assessments.
  • the present invention relates to a tool for synthesizing an economically optimal routing, characterized in that: the different configurations of service variants and of computer variants being specified and the rate of occurrence of these configurations being known, the sum of the configuration rates being equal to one,
  • the optimal routing in quality is synthesized, characterized in that the steps above are repeated, the criterion which is minimized being a measure of quality preferably expressed in breakdowns per million.
  • the optimal routing by weight is synthesized, characterized in that the steps above are repeated, the criterion which is minimized being a quality measure preferably expressed in breakdowns per million.
  • an installation cost of the electrical and electronic architecture is automatically calculated as a function of a cost of mounting a strand on a zone, of a cost of mounting a connector on a zone border or on a zone, a cost of mounting a computer on a zone, a cost of mounting a sensor or an actuator on a zone and a cost of connecting a connector between zones or in an area.
  • the optimal routing for all the configurations is synthesized, repeating the above steps, the criterion which is minimized being a compound cost:
  • All of the process operations can be performed using a computer.
  • the method according to the invention can be applied to the synthesis of the electrical architecture of a newly created product.
  • the method according to the invention can also apply to the synthesis of a modified electrical architecture compared to an earlier architecture.
  • FIG. 1 schematically represents the different stages of the method according to the invention
  • FIG. 2 is a top view, in plan of the various zones of a motor vehicle
  • FIG. 3 is a schematic view of elements for describing zones
  • FIG. 4 shows routings validated in a door area of a vehicle
  • FIG. 5 shows an example of the wiring of a vehicle door
  • FIG. 18 shows steps implemented in a method of designing a system architecture according to the present invention.
  • vehicle and “product” are used interchangeably, the scope of the present invention not being limited to vehicles but the particular embodiments being detailed for a product consisting of a vehicle. - the terms “estimate” and “evaluation” are used interchangeably.
  • tool means "system architecture design tool”.
  • component will generally refer to a sensor or an actuator as opposed to a computer.
  • An electronic component will on the other hand be as well an actuator or a sensor as a computer or another intelligent component also called in English "smart component”.
  • An electronic electrical component will designate any type of component. In practice, these distinctions will be clear from the context of use.
  • FIG. 1 schematically represents the stages of the process followed to carry out the routing of the wires of the electrical and electronic architecture as well as its evaluation. Certain links between some of the stages are symbolized by arrows. For example, the arrow between steps 102 and 104 indicates that step 104 is performed after step 102. On the other hand, there is no link between step 104 and step 106, these two steps can be performed in any order without affecting the quality of the result.
  • the method comprises:
  • step 102 during which the geometry of the vehicle is specified, in the form of zones, for example by using a computer which displays the screen illustrated in FIG. 13 and has software enabling the functions described in look at Figure 13; At the same time as this step 102, at least one of the following choices is made:
  • step 104 during which so-called "avoidance" sub-zones are placed in the zones defined during step 102, as explained with reference to FIGS. 13 and 14;
  • step 106 during which routing points and connectors are placed, in particular between the zones defined during step 102;
  • step 108 during which the components are placed a step 110 during which the software which implements the first aspect of the present invention automatically performs a synthesis of the routing of the signals, an example of such routing being presented in FIG. 5;
  • step 114 during which the software automatically performs a synthesis of the mass links, an example of such routing being proposed in FIG. 5;
  • a step 118 during which the software automatically performs an evaluation of the quality of the routing on the basis of functions for estimating the quality of the connectors and the wires as a function of their size and of functions for estimating the quality of the various electronic components;
  • a step 120 during which the software automatically performs an evaluation of the weight of the routing, from functions for estimating the weight of the connectors and the wires as a function of their size and from functions for estimating the weight of the various components electronic.
  • steps 106 and 108 for an improvement and the synthesis steps 110, 112, 114 are repeated to proceed. to a new evaluation and iteratively converge towards an optimized solution.
  • Figure 2 schematically represents the division into zones of a product, in this case a 5-door motor vehicle with a tailgate. The different areas of the vehicle are shown in a top view.
  • These different zones include: a right front wing zone 202, a right front door zone 204, a right upright zone 206, a right rear door zone 208, a right rear wing zone 210, a right front upright zone 211, a rear upright zone right 212, a tailgate area 214, a roof area 216, a cockpit area 218, a hood area 220, a front left upright area 222, a right rear upright area 224, a front face area 226, a front left wing area 228, a front left door area 230, a left upright area 232, a right rear door area 234, a left rear wing area 236, and a floor area 240.
  • These zones are, in FIG.
  • Compass 238 indicates how the zones are located relative to each other, but does not apply to each zone in particular.
  • the "right front wing" 202 and “right front door” areas 204 are placed so that it can be deduced that the "right front wing” area 202 is at the front of the "front door” area right "204.
  • these two zones are vertical and, locally, will not be represented according to the directions indicated by the" compass "238.
  • FIG. 3 schematically represents elements for describing zones and illustrates how are placed on a "horizontal floor zone" zone 318 corresponding in FIG. 2 to the floor zone 240, a connection point 302, a routing point 312, a connector placed in place of a routing point 304 or in place of a connection point 316, an avoidance zone 314, components 306 and 308, whether they are sensors, actuators, electronic control or fuse and relay boxes.
  • Zone routing is carried out, the component 306 being routed to the connection point 302 via the connector 304 and the component 308 being routed to the connector 316 via the routing point 312.
  • FIG. 3 illustrates the connections between zones schematized by the broken line between, on the one hand, the connection point 302 of the horizontal floor area 318 and the connection point 320 of the connected vertical area 324 and, on the other hand, the connector 316 of the horizontal area floor 318 and the connector 322 of the connected vertical zone 324.
  • the "compass" 326 indicates how to orient the horizontal zone floor 318 while the "compass” 328 indicates how to orient the connected vertical zone 324.
  • connection points 302 and 320 when associated, represent the same point in space, that is to say a point of physical contact between the horizontal floor areas 318 and related vertical 324.
  • the connectors 312 and 316 are joined by a standard "male / female plug" type mechanism, for example the connector 312 is a male connector and the connector 316 is a female connector and these two connectors are physically linked at a physical point of contact between the horizontal floor areas 318 and associated vertical areas 324.
  • FIG. 4 diagrammatically represents valid routes in a left front door zone 414 corresponding to the left front door zone 230 illustrated in FIG. 2.
  • the avoidance sub-zones 418, 420 and 422 are hatched, and components are shown, in particular a window regulator control button 402, a window regulator control button light lamp 404, a locking motor 406, a window regulator motor 408, connectors 410 and 412. Reading of zone 414 is simplified using the "compass" 416.
  • routing points 451, 452, 457 and 458 have been placed. It is noted that certain vertices of the avoidance subzone 422 are specifically useful for routing, that is to say electrical wires or links, 454, 455 and 456.
  • FIG. 5 schematically represents a routing of a set of wires over two zones, on the one hand, a left front door zone 414 and, on the other hand, a cockpit zone 510.
  • FIGS. 4 and 5 Some components are common to FIGS. 4 and 5. Others, in particular in the cockpit area 510 are added: a ground point 504, an electronic control unit 506, a fuse and relay box 508 and the connectors 502 and 512, corresponding respectively to connectors 410 and 412 of the front left door zone 414. The link between the connectors of the two zones is symbolized by the dotted lines in FIG. 5.
  • the connectors 502 and 410 are joined by a standard mechanism type male / female socket as shown opposite figure 3.
  • a two-dimensional representation of the product is carried out as follows: the product is divided into zones, the dimensions of which must be specified in order to best match the geometry of the product considered.
  • This representation is in particular satisfactory for a motor vehicle insofar as the wiring can be largely fixed directly to the sheets and therefore to a breakdown of the vehicle into flat areas, as detailed in FIG. 2.
  • Each zone represented is preferably vertical or horizontal.
  • a tilted tailgate you can choose one or the other of the representations.
  • the aim of these guidelines is in particular that a person skilled in the art can easily find his way from one zone to another, or from a global view, in which all the zones are represented, to a local view, in which a only one area, for example, is shown.
  • Figure 2 shows a top view of the different areas of the upper part of a five-door passenger compartment (including the tailgate).
  • Each zone can contain avoidance sub-zones, that is to say zones in which no wires can be passed.
  • avoidance sub-zones that is to say zones in which no wires can be passed.
  • the window will correspond to an avoidance sub-area.
  • each zone has its frame of reference and the avoidance sub-zones of a zone A are forms inscribed in A, preferably in the form of a polygon or a quadrilateral.
  • Figure 3 represents a zoom on an area of the type described in figure 2. It is an area inscribed in a horizontal plane as indicated by the compass
  • a hatched shape indicates an avoidance sub-area 314.
  • Each zone is, moreover, linked to the other zones by connection points which are used to specify the geometric links between the different zones and to specify locations where the wires can pass from one zone to another.
  • a connection point between two zones is therefore represented on each of these zones.
  • a connection point can be a connector. In this case, there is a connector on the two areas it links.
  • FIG 3 the link between two areas, through connection points, is illustrated.
  • the "horizontal floor area” area 318 is linked to the "connected vertical area” area 324 by two connectors 302/320 and 316/322. These two connectors are located at equal distance from each other on each of said zones.
  • the routing points are wire grouping points proposed, in each zone, by the designer and which make it possible in particular to group the wires into strands.
  • all the vertices of an avoidance sub-area are routing points so that there is always a solution to the problem of routing in an area.
  • a routing point can be a connector.
  • Routing between two points consists of a sequence of routing or connection points.
  • the wire synthesized according to a routing is assumed and represented rectilinear between two successive routing or connection points.
  • a routing is said to be valid in an area if, on the one hand, it does not cross any avoidance sub-area and if, on the other hand, given two successive routing or connection points A and B of the routing, then there is no routing point C attainable without crossing an avoidance sub-area and such that the lengths of the segments AC and BC are less than the length of the segment AB.
  • a route crossing several zones via connection points between zones is valid if it is valid in each zone.
  • the length of the routing of a wire is the sum of the distances between the successive routing or connection points which form the routing. Routing is optimal if the routing length is minimum among all possible valid routes.
  • points 451, 452, 453, 454, 455, 456, 457 and 458 are routing points.
  • Points 410 and 412 represent connection points between areas containing connectors.
  • 454, 455 and 456 are also vertices of an avoidance subzone.
  • the routing (406 - 451 - 452 - 458 - 412) cannot be appropriate because it crosses an avoidance sub-zone.
  • the shortest route respecting all the clauses is (406 - 454 - 455 - 456 - 458 - 412).
  • the routing calculation is done between two components rather than between a component and a connection point with or without a connector in an area. The following electronic and electrical components are placed on the different product areas.
  • These components are: electronic control units: these are electronic components capable of controlling data signals, that is to say of low power, used in particular to transport software data or data interpretable by software, in particular coming from a sensor or to an actuator; sensors and actuators; fuse and relay boxes: these are electronic components capable of controlling both low-power and high-power signals, which are simply referred to as power signals; - sources: are energy sources, typically a battery - a source can be compared to a particular fuse and relay box; The electronic control units preferentially ensure the logical control of the components while the boxes ensure the relay of their supply and the sources supply the supply of the assembly.
  • the fuse and relay boxes contain for example the fuses protecting the different loads (components consuming energy) placed on the different wires linked to the said boxes and also preferentially contain relays allowing the activation of the loads requiring power.
  • the various elements of the electrical and electronic architecture are represented by points, that is to say associated with two coordinates in the frame of reference of the area on which they are placed. Ground points are also placed. The ground points are such that a so-called ground wire, connected to a ground point, is at zero electrical potential. Ground points are specified by the designer.
  • the electrical and electronic architecture is given by: the choice of electronic control units, - the choice of communication networks, the choice of sensors and actuators, the choice of fuse and relay boxes, the logical links of these different components to each other These links are, in particular, the connections of the electronic control units and of the fuse and relay boxes to the various communication networks. These links can also be explicit links between a sensor or actuator and an electronic control unit or a fuse and relay box. In particular, since for example a sensor can have several electrical links with its environment, for example a ground link, a power link and a link for the transmission of information, said sensor can be simultaneously linked to a ground, a fuse and relay box and an electronic control unit.
  • the routing of all the wires is carried out in stages for a given placement of the various elements of the architecture.
  • the network topology characteristics must be known: such a network is preferably organized in a star, in line or in a loop depending on the case.
  • star or online topologies are possible.
  • the designer will indicate his recommendation.
  • the reasons for choosing a topology are very varied.
  • the star network may be preferred for reasons of operational safety because in the event of a bus interruption, only one computer is isolated while in the event of an online topology, the network is cut in half and the consequences are a a priori more serious.
  • the electrical characteristics of the various components can be specified: number of interface pins, nature of pins (data, mass, power), attachment of data or power pins if they are specified, minimum operating voltage, average current, inrush current, power consumed, and this for each power wire leaving the component.
  • the routing evolves consequently since it is necessary to route each wire separately and to specify a pin for each connector involved in the routing of a new wire.
  • the motors 406 and 408 can each have three data wires, power and mass, respectively, and therefore comprise connectors with three pins.
  • the links to earth M 504 and to the BFR 508 fuse and relay box, which had not been expressed until now, appear in the form of new routes: - locking motor 406 / pine 1 at ECU 506 / pine 1 (data): (406 / pine 1 - 451 - 452 - 410 / pine 1, 506 / pine 1),
  • each wire connects a pine of a connector of a component to a pine of another connector of another component and passes, moreover, by a certain number of routing and connection points as specified above. It is the data of the two connectors and the pins of each connector at the ends, that is to say at the level of the connected components, the sequence of routing points, as well as the sequence of the pins of the connectors, in particular between zones, crossed, which logically defines the wire.
  • the logical wiring plan is the data for all the logical definitions of the wires that constitute it. - the specification of the connectors: for each connector, it is the number of connections corresponding to data wires, the number of connections corresponding to power and the number of connections corresponding to ground wires which constitute the specification.
  • connector 410 now provides five connections, three of which are data, one power, and one ground.
  • the user may also wish to calculate or evaluate the cost of an electrical and electronic architecture, in particular in order to compare such architectures and choose the least costly with equal service and quality.
  • a cost function of connectors for example based on a chart which gives an estimate of the price of connectors according to the number of data, power and mass connections, or based for example on an average price assigned to each connection of a data wire, current or ground.
  • wires Given a cost function of wires based for example on their length and on their type, taking for example an average linear weight for power and mass wires, an average linear weight for data wires, and a mass cost of the component in which said wires are produced.
  • a cost evaluation is automatically deduced from the technical specification for the electronic and electronic architecture considered by summing the costs of all the electronic components, all the connectors and all the wires.
  • the cost of an operation is: (N / P) * CI + N * n * CROM + MEMO * n * CRAM.
  • some instructions occupy 16 bits, which in particular saves memory. This characteristic can be taken into account by separating these two types of instructions if one can evaluate a mix for the elementary operation considered and by consuming half the ROM for the instructions on 16 bits.
  • the cost C1 of the execution of an instruction per second on a processor can depend on the type of application that is processed, all the instructions not being carried out in as many cycles.
  • the estimate of the number of line of code is determined according to the number of state and the number of transitions and the period of activation is determined according to the performance requirements for the different use cases.
  • the cost of the various hardware pilots can be assessed according to their type (all or nothing, analog-digital, etc.) and their electrical characteristics.
  • the user may also wish to evaluate the quality of an electrical and electronic architecture, in particular in order to compare such architectures and choose the one which presents the best level of quality, with identical service and cost.
  • the measurement of quality is preferably done by measuring the number of failures per million units and per year of the entire architecture, preferably using software.
  • the software measures the quality of all the connectors, whether they are connectors between zones or within zones or input / output connectors of electronic components (sensors, actuators, electronic control, fuse boxes and relays) by assigning for example an average failure rate per connection, for example 10 ppm (failure per million units per year) and by multiplying this average rate by the total number of connections in the system.
  • the software takes into account averages adjusted according to the type of connection: mass, power and data, the finest wires being the most fragile. For example, we take 4 ppm per connection of power or ground wires on a pin and 6 ppm per connection of data wires on a pin, and finally an estimate of 4 ppm per portion of data wire between two connectors.
  • the ppm corresponding to the duplication of wires downstream of the splice, seen from the actuators 406 and 408, are to be deleted, ie 3 * 4 ppm.
  • a power splice we find 88ppm as the quality of the optimized routing.
  • a mass splice at the same routing point saves another 12 ppm to reach 76 ppm. Optimization on a cost estimate would similarly consist of eliminating the cost of the portions of wires and connector pins removed by means of the splice.
  • the tool measures the quality of electronic components which is specified in a database of components and can be described according to the type of component or specifically for each component, for example we can attach an evaluation at 100 ppm to all units electronic control. "The tool then adds the measurements of all components constituting the electric and electronic architecture.
  • the user can also refine the routing strategy by integrating splices for power wires and ground wires.
  • These splices can be made at the connectors or within an area, preferably at a routing point.
  • Making a mass splice consists in joining all the (n) ground wires passing through a point, and in particular at a connection point or a routing point. In this way, going back to the nearest mass, one saves on the one hand wires and on the other hand connection pins corresponding to the (n-1) wires removed.
  • Making a power splice consists of joining power wires which, on the one hand, pass through a common point, in particular through a connection point or through a routing point, and, on the other hand, join loads to a common fuse and relay box.
  • the power wire of the locking motor 406 and the wire lamp 404 supply can be joined at the routing point 452 or at the connector 410.
  • Such splices are used to save pins at the connectors and the pieces of wire thus removed.
  • Point 452 is the one that minimizes the lengths of wire for the realization of the splice in the example of figure 5.
  • Practicing a splice at the level of a connector amounts to linking together the pins of the connector corresponding to the wires that one wishes to join.
  • FIGS. 6 et seq. Describe a system architecture design tool and a method for designing a specification of a hardware and software system implementing this tool.
  • This tool is particularly suited to the case of complex systems comprising a set of computers performing numerous services or benefits for the benefit of a user, each service has many use cases.
  • vehicle electronic and computer systems are particularly targeted by this tool.
  • Services are defined by what the user wants (for example the start of air conditioning, wipers) or by what is offered (for example passive safety, especially in the event of accidents) . They are also defined by sensors and / or actuators which they implement. They each correspond to a sensor / software / actuator hardware implementation.
  • the manufacturer has a margin of maneuver in the definition of the internal architecture of the electronic / IT system, in particular in the choice of on-board networks and electronic boxes connected to these networks and the design tool presented here allows the design of this architecture. From the services, the design tool makes it possible to determine specifications rather than finished products. However, this tool also determines interfaces and what must include the elements and their communication with the electronic / computer system.
  • this tool does not aim to program the computers automatically but to manage cost / quality / time compromises of the specified system.
  • the design tool is implemented in the form of software running on a personal computer and using a known database and resources (operating system and distribution over the network).
  • each service represents a service rendered to a user
  • each formalized use case comprising an original context, a user request, possibly implicit, and a response from the system corresponding to a change in its state , and - the system is organized and specified to perform the response, upon detection of emission of the request in the original context.
  • the method comprises a step of designing, for each service, an automatic service control controller intended to be implemented by the system of hardware and software components and which represents the behavior of this system.
  • This design step includes, for each service, a step of defining a formalized use case of the service, specified by a context, a request from a user to the system and a response from the system corresponding to a change in its state. and, iteratively, until all cases of use of the service have been treated: - a step of adding a formal use case of the service, specified by a context or initial situation of the system, a request from a user to the system and a response from the system corresponding to a change in its state,
  • the service control automaton consisting of all the state pairs linked by the requests forming the transitions of said automaton is synthesized.
  • the context represents at least one mode (or parameter) of operation of the system, the modes being transversal to the services and outside of direct control of the services, for example a mode representing a level of available energy (low battery, on battery, in progress starting mode, with the engine running, for example), another mode representing a type of system user (designer, manufacturer, vehicle owner, vehicle driver or passenger, after-sales service, car garage, for example) and another mode representing an accident or not state of a vehicle.
  • a mode representing a level of available energy low battery, on battery, in progress starting mode, with the engine running, for example
  • another mode representing a type of system user (designer, manufacturer, vehicle owner, vehicle driver or passenger, after-sales service, car garage, for example)
  • another mode representing an accident or not state of a vehicle for example, but not, the change in available energy level (linked to the alternator being driven by the engine) is not directly under the control of this service.
  • any context is part of a system life phase consisting of a combination of vehicle operating modes, the declination in phase mode thus being transversal to the services.
  • a context will correspond to a set of couples (phase, state of the system), each state being in fact characterized by the system response when accessed.
  • the use case "in the context where the vehicle is condemned, the user presses his unlocking badge and the vehicle unlocks” applies to the "vehicle locked” states in the “engine running” phases and “engine stopped”, if these two phases have been identified as relevant by other formalized use cases of the "unlocking" service.
  • Each phase corresponds to a set of combinations of modes in which the behavior of the service is uniform, that is to say that the same states and the same customer requests are observed, or, put differently, the same customer requests and same system responses from a given state.
  • the table below defines a set of phases for a given vehicle.
  • the tool allows a completion step during which, for each response, that is to say a state of the system, we consider all the customer requests not yet processed and we ask the designer if a processing of the request must be performed in the state corresponding to this response. Only customer requests can have an effect on the service.
  • the design tool also allows for a correction step during which if, in the same starting state, two states of the service control automaton are linked by different requests, then the need to define a priority between system responses and this priority is incorporated as an attribute of the state outputs.
  • Priority information typically comes after the design of formalized use cases. It is possible that for mechanical or other reasons, two potentially competing demands may never in fact be possible simultaneously. In this case you have to wait for a more advanced design step to be sure that it is not necessary to specify a priority, unless this can be guaranteed directly (for example: opening a door and closing the same door cannot be done simultaneously).
  • two identical requests lead to different states, then there is an inconsistency to be corrected and one of the requests must be deleted and the corresponding use case must be specified accordingly.
  • each change of context is a change of state object of a CUF
  • a service is added for the intersection part, so as to resolve conflicts between services.
  • the purpose of this service will be to arbitrate when two concurrent actions are applied to a component given by two services, which of the services takes precedence or if a specific action corresponding to this particular case must be carried out.
  • Such a service is typically not specified from the use case but rather by identification of the states of the two services in which reactions leading to conflict (with respect to one or more given components) are identified.
  • the service control automaton is produced by programming at least one control computer for the corresponding service.
  • the tool has different pages accessible by clicking on tabs. These pages are described with reference to Figures 6 to 16. For the sake of clarity, in Figures 6 to 16, the titles of the tabs and list items selected by the designer are underlined and in bold.
  • the user interface 600 of this software tool comprises:
  • the drop-down menus 601 to 608 are represented by their titles “File”, “Edit”, “View”, “Dictionaries”, “Windows”, “Tools”, “Import / export” and "Help”. By clicking on one of these titles, with the left mouse button, a drop-down menu appears with options participating in the implementation of the process (opening, editing, saving, closing a file, cutting, copying, paste selected elements, viewing modes, lexicon, tools, import or export of files, help ). When working on the design of an electronic and computer system architecture for a vehicle, the designer does not necessarily have to use these drop-down menus 601 to 608.
  • the design tool presents a screen comprising a hierarchical list part (on the left in FIGS. 6 to 16) representing a hierarchical description and a graphic part (on the right in FIGS. 6 to 16) giving, as a function of a selection, via a pointing device (in the description below, a mouse), of an element of the hierarchical list, a synthetic view concerning the element selected.
  • a hierarchical level of the hierarchical list represents services.
  • the first three tabs 611 to 613 have this characteristic.
  • the horizontal tabs have the following titles:
  • the designer first selects the 611 "Requirements" tab and observes the screen illustrated in FIG. 6.
  • the hierarchical list box 620 which includes a part d '' a list with the five highest hierarchy levels: vehicle name services or services service variants use case link between states
  • the level elements lower hierarchical may be apparent or not.
  • the list apparently only contains vehicle names
  • the list of services offered on this vehicle appears.
  • the list of service variants which concerns it is made apparent, and so on.
  • a use case is, in the design tool, defined by an initial phase (for example an available energy level) transverse to the vehicle, an initial state (for example the position d actuators), a request or request, a final phase and a final state.
  • an initial phase for example an available energy level
  • an initial state for example the position d actuators
  • a new use case (CU) is added concerning what must be done following a serious accident.
  • CU new use case
  • the name and description are called “properties" of the new use case.
  • the interface is represented, when the "User opens trunk" use case is selected.
  • the interface is represented, when the "User opens trunk" use case is selected.
  • graph area 630 Depending on the level of the item in the hierarchical list selected, in graph area 630: - name of the vehicle: the list of services
  • phase 1 and phase 2 indicating the phases concerned, "phase 1" and "phase 2", of the initial states 660 to 663 and terminals 664 to 667 represented by rectangles and linked by links 668 to 671.
  • a contextual menu includes four zones, “initial phase”, “initial state”, “final phase” and “final state” which make it possible to select between all the phases already defined or between all the states already defined, those which represent the use case.
  • the "brake" service has four phases: - emergency braking,
  • the air conditioning service two phases are defined, one for the low levels of available energy, for which ventilation is carried out without cooling the ventilated air, which consumes too much energy, and the other for the case of the engine running, the air conditioning being carried out with cooling of the ventilated air.
  • the operating algorithm of a service is represented by rectangular blocks, representing states, and arrows, representing an action or inaction causing a transition between states.
  • states representing states
  • arrows representing an action or inaction causing a transition between states.
  • a transition represents a request from the client. For example, a click on a boot opening badge changes from the "all closed” state in which all the doors of the vehicle are closed, to a "doors closed / boot open” state. For each state, a set of elementary operations is thus defined which must function or be executed in said state. All the states and transitions form a control automaton associated with the service.
  • the states can be considered as "felt customers", the transitions being the requests of the customer, possibly implicit. It is understood that the phases are attributes of the states but that two identical states with the exception of their phases ("before contact” and "after contact” phases, for example) are considered as two independent states.
  • FIG. 7 illustrates an image of the user interface which is then displayed on the screen of the design station.
  • the user interface 700 of this software tool then comprises: the drop-down menus 601 to 608,
  • the vertical tabs 731 and 732 are respectively named “functional diagram” and “feature” and are attached to the graphic area 730. They are used to select a content to be displayed in this graphic area 730, as shown further.
  • the hierarchical list box 720 includes a part of the list, the ten highest hierarchy levels of which are: vehicle name services or services service variants phase state group of elementary operations elementary operation given driver ("driver”) ) component.
  • driver phase state group of elementary operations elementary operation given driver
  • the selection of one of the components of the hierarchical list, by a left click causes with the tab "feature" 732 selected, the appearance, in the graphic part 730, of all the elements of the level list immediately lower with sometimes a flow of control between the components if we point and click with the mouse on service variant (the phases appear in the left part linked together by customer requests corresponding to transitions of phase) or on a phase (the phase states appear on the left, linked together by "customer requests").
  • the tool allows you to add or remove elements in the hierarchical level immediately below.
  • an elementary operation transversely in said phase respectively, that is to say in all of the states of said phase and in indicating in which group of elementary operations we add said elementary operation, in said state in particular by indicating in which group of elementary operations we add elementary operation in said state, and in said group of elementary operations.
  • the tool By right-clicking on the phase item of the hierarchical list 720, it is possible to add a phase transition, the tool then requests the arrival phase, the customer request corresponding to the transition, and the states of departure and of arrival for the phase transition.
  • the state item in the hierarchical list 720 it is possible to add a state transition, the tool then asks what is the arrival state of the transition and what is the corresponding customer request.
  • the elementary operation groups represented as the nodes of an oriented graph, each arrow representing the flow of data between the group of elementary operations of departure and the group of operations of elementary arrival.
  • This data flow is defined with respect to the data flow between elementary operations, insofar as any data appearing is in fact produced by one or more elementary operations of the group of initial elementary operations and consumed by one or more elementary operations of the group of elementary arrival operations.
  • phase envelope view of diagram type illustrated in FIG. 8 for the elementary operations of the phase and by restricting the other services to mode combinations of the state phase envelope view of diagram type illustrated in FIG. 8 for the elementary operations of the state and by restricting the other services to the mode combinations of the phase in which the state is specified.
  • - group of basic operations as when the "functional diagram" tab is selected
  • - elementary operation a graph with in the center the selected elementary operation and around it the sensors, actuators and other elementary operations of the architecture as a whole to which it is linked the edges of the graph are the data flows between the nodes .
  • - data the elementary operations, sensors or actuators to which the data is directly linked are displayed in a graph.
  • the sensors or elementary operations which produce the data appear to its right while the actuators or elementary operations consuming the data are placed to the left of the data.
  • the arrows indicate the direction of passage of the data (from producer to consumer).
  • - pilot the characteristics of the pilot, type of analog / digital input / output, all-or-nothing, its electrical characteristics.
  • actuator a graph with in the center the selected sensor or actuator and around it the elementary operations of the architecture as a whole to which it is linked, the edges of the graph are the data flows between the nodes .
  • "functional diagram” 731 is selected, in the graphical part 730, the corresponding automaton is observed, with states (or operational situations) and the only phase transitions.
  • states or operational situations
  • FIG. 7 we see an automaton corresponding to the "badge” variant of the "opening service” service: states 761 to 766 and transitions 768, 769 and 772. If we click with the left button on an arrow representing a transition, we sees a popup menu that describes all the requests that cause this transition. Generally only one request causes this transition, for example the request "contact_on” which corresponds to the setting of the contact, for example with the ignition key, makes pass from the phase "contact not put” to the phase "contact put", but more than one formal use case request can link two states.
  • the fourth level of hierarchy concerns the phases.
  • a phase is selected, and the "functional diagram" tab 731 is selected, in the graphic area 730, under the name of the phase, the names of the states which correspond to it are observed, in rectangles.
  • a contextual menu which allows, among other things, to link the phase to the modes (we observe, in a contextual menu a list of modes, by example energy, customer, state of the vehicle with check boxes to associate the phase with combinations of modes). For example, the "crash" phase is specified in modes where it is valid.
  • elementary operations are organized in groups to facilitate navigation.
  • the operation groups include the same basic operations for all the horizontal tabs 611 to 616.
  • an elementary operation we observe, in the graphic area 730, the flow of data (in English "data flow"), that is to say the data exchanged by this operation (given in input and output rectangles).
  • a group of elementary operations is selected, in the sixth one observes, in the graphic area 730, the flow of data between the elementary operations which it comprises.
  • a state at the fifth level of hierarchy, we observe, in the graphic part 730, the flow of data between the groups of elementary operations which it comprises.
  • For each of the fifth to seventh levels if one selects a link in the graphic part, with a click on the left button, one observes, in a contextual menu, a list of the exchanged data. By selecting one, you can modify it (see below).
  • component are known elsewhere and come from the vehicle manufacturer's library, from equipment manufacturers or from suppliers.
  • a hierarchical list Phase / State / Group of elementary operations / Elementary operations / Data / Pilots / Components of the two services selected with at the different levels of said hierarchical list which one selects, a "+" sign when only the service variant selected first includes the elements of the selected level, a "-” sign when only the service variant selected second includes the elements of the selected level, an "I” sign if there is a difference at a level lower than the level selected, and no particular sign if the two hierarchical lists of the service variants compared are identical at this level
  • - services or services the list of service variants, service variants the graph whose nodes are the phases and the arrows oriented customer requests for phase change, phase: the set of states in a diagram such as that shown in Figure 7,
  • FIG. 8 One of the screens corresponding to this selection is illustrated in FIG. 8.
  • This envelope 840 is represented in the form of a rectangle, divided horizontally into two rectangular parts.
  • the upper part is connected, on the left, to representations of the sensors 851 which supply it with data and, on the right, to actuators 852 and 853, to which the service variant supplies data.
  • the lower part is connected, on the left to incoming data 856 and 854 and, on the right, to outgoing data 855. The data which only pass through the variant, without being used (or consumed) is not shown.
  • an exclamation point indicates a supposed conflict (for example in the case where, at the output, several services claim to provide the same data) which supposes to resolve an arbitration problem, a question mark next to an incoming data item for which no element has yet been defined to produce it.
  • This representation of envelope 840 gives a very practical summary view for the user of the design tool. If, in the envelope representation, a data, a sensor or an actuator is clicked, a functional view is obtained, indicating the elementary operations which produce the data and those which consume it. If one selects or clicks on one of these elementary operations, then one sees in a new screen the list of the computer variants on which this elementary operation is placed. This display is performed in a new window. Which appears when you double click. If you click on a sensor or an actuator, you get the list of service variants using this component as well as the list of computer variants to which the component is attached. The return to normal takes place by closing the windows thus created.
  • the services with which the selected service exchanges data appear directly in boxes like 855 directly associated with the input and output data of the service.
  • boxes like 855 directly associated with the input and output data of the service.
  • the user interface 900 of this software tool then comprises:
  • the vertical tabs 931 and 932 are respectively named “networks” and
  • “feature” and are attached to the graphics area 930. They are used to select content to be displayed in this graphics area 930, as explained below.
  • the hierarchical list box 920 which includes a part of the list whose seven highest hierarchy levels are: name of the vehicle services or services variants of service group of elementary operations elementary operation pilot data
  • the three highest hierarchy levels are identical to those of the hierarchical lists 620 and 720 and, in particular, include services.
  • the selection of one of the components of the hierarchical list, by a left click causes, with the "network" tab 931 selected, the appearance, in the graphic part 930, of all the networks 941 to 943 of computers 951 to 955, synthetic representation making it possible to observe, for the selected element, its distribution on the computers and the data flows which concern it on the networks.
  • the "network" tab 931 is active, all of the networks (the nodes and the different networks) are active.
  • Each network is represented with all the computers connected to it, the network having a specific color, represented here by stickers, vignettes or pads 961 to 963 bearing signs "+", "x” or “o".
  • Computers present on two networks, computers 951 and 955, are, on each network to which they are connected, equipped with "sticker (s)", each "sticker” having the color, represented here by the sign corresponding to each other network to which the computer in question is directly connected.
  • the stickers thus give a three-dimensional view without complexity of representation.
  • This average duration is estimated for example by taking into account the communication protocol implemented on the network considered and displayed in the popup window and the performance of this protocol, for example - the level of load saturating the network (from 30% load for the CAN we observe that the most critical frames may not arrive in due time because of the arbitration mechanism which delays the transmission of a frame when transmission of another frame of higher or equal priority has already been requested, and the share of data flow that is part of protocol management (50% for CAN, typically because the protocol management data (arbitration, CRC, 7) represents practically as many bits on average as the data actually transported by a frame).
  • the data flow calculation is done by mode and the highest load is taken in the mode in which it appears. This aspect motivated by the fact that for example, in diagnostic mode, certain frames corresponding to a client mode are inhibited and therefore are not taken into account in the load calculation. Conversely, the load calculation in the operation for the end customer must not take into account the diagnostic frames.
  • a frame is transmitted in a given mode if and only if at least one of its data is exchanged between two elementary operations active in this said mode.
  • the user of the tool can perform the placement (in English "mapping") of a service variant or a group of elementary operations, or even of a elementary operation selected in the list box 920, on one or more computers represented in the graphic part 930, by the well-known function of "drag and drop” (which one can translate, in French, by "to move and to let go” ).
  • drag and drop which one can translate, in French, by "to move and to let go
  • the different types of placement include, in particular, placement on a single computer, placement in master and slave and distributed placement.
  • the "control" part of the service sends control messages on at least one network to control each slave and the tool automatically adds these control messages inside or outside the already defined frames (to see further).
  • an elementary operation representing the service control automaton, is automatically added in relation to the service variant considered. It is called "elementary control operation”.
  • the service variant, or a group of elementary operation or an elementary operation and in particular the elementary control operation are placed on a variant of computer.
  • There are as many slaves as there are nodes on which the elementary control operation is not placed and on which at least one elementary operation of the service is placed.
  • the node on which the elementary operation for controlling the service is placed is the master node.
  • the type of placement distributed means that elementary operations of the same service are distributed over several computers and that, on the other hand, the service control automaton is synthesized on each of said computers. We therefore automatically add to each node on which at least one elementary operation of the service has been placed at the time of placement an elementary control operation which represents the service control automaton. This elementary control operation is the same as that which one would have synthesized automatically for a placement of type master - slave.
  • a placement dialog box appears asking if the elementary operations, the sensors and actuator concerned should be placed simultaneously and on the same computer. If it is decided to place the service with the actuators and / or sensors concerned, the design tool connects them to the computer. If the elementary operations, the sensors and / or the actuators are not placed on the same computer as the rest of the service, the design tool adds the data necessary for the proper functioning of the service in or outside the frames already defined (to see further).
  • FIG. 11 shows a user interface displayed when the 614 "OPER" tab is selected.
  • the user interface 1100 of the software tool then comprises:
  • the hierarchical list zone 1120 which includes a part of the list whose six highest hierarchy levels are: name of the vehicle type of calculator variant of calculator service elementary operation pilot data
  • the user interface 1200 of the software tool then comprises:
  • the hierarchical list box 1220 which comprises a part of the list whose six highest hierarchy levels are: name of the vehicle type of calculator variant of frame calculator given in the sensor / actuator frame pilot data
  • vehicle name the networks of this architecture vehicle type of computer the networks to which this type of the computer is connected, represented in FIG. 16 variant of the computer the networks to which this variant of the computer is connected frames or the network to which this frame belongs given in the frame the network to which this data belongs (via the frame) sensor / actuator the type of computer to which this component is connected and the networks to which this type of computer is connected.
  • the links of the computer variant to sensors or actuators are displayed, the links to sensors being displayed on one side 1252 and the links to actuators being displayed on the other side 1250, 1254.
  • the data appears inside the contour 1260, while the name of the sensor "Key" appears outside the contour.
  • the designer can easily distinguish the names of the data of the application software embedded on the computer variant, of the names of the different sensors and actuators, and moreover the link of the sensors / actuators to the software data is clear.
  • the messaging interfaces of the selected computer variant This messaging interface consists of message frames consumed or produced on the various networks to which the selected computer variant is connected.
  • the consumed frames are represented on one side of the zone, and the outgoing frames on the other side.
  • T_in_1, 1246 is an incoming frame
  • T_out_1 and T_out_2, respectively 1247 and 1248 are transmitted frames.
  • Only the data actually consumed and produced by at least one elementary operation on the selected computer variant are represented in area 1244 in correspondence with the different frames. For example, if a location for a data item "n" is reserved in T_in_1 and if the data "n" is not consumed by any elementary operation on the selected computer variant, then "n" does not appear in area 1244.
  • sensor / actuator a rectangular outline (not shown) separated into two parts, the top part being used to indicate the data produced by the sensor / actuator using a pilot and used on other computers than that to which the component is attached, the lower part being used to represent the data produced using a pilot and used on the computer to which the component is attached.
  • the data received by the component is on the left of the outline while the transmitted data are on the right of the outline.
  • Such a data-computer link is represented similarly to the data-service link 855 in FIG.
  • the data circulating on a network are visible in a dialog box when one clicks with the right button on the network in question, the tab "networks" 1232 or 1232 being active.
  • This dialog uses colors to indicate the placement in a frame and the use of the data, as explained above, with reference to FIG. 9.
  • a popup menu allows you to reach a contextual dialog box which provides information on this data item, in particular, the dimension ( a boolean at a size of one bit), the extreme values, a default value and the maximum age of the data, i.e. duration after capture after which the data can be considered obsolete ... etc .
  • FIG. 13 represents a screen 1300 for entering and displaying the zones of a product called "vehicle Z23" for which it is desired to build an electrical and electronic architecture.
  • This screen can be accessed from any of the screens in Figures 6 to 12 by selecting from the tools menu 606.
  • the graphic part, on the right of the screen comprises an upper zone in which three buttons 1312, 1314 and 1316 are shown.
  • the different areas of the vehicle on which the components of the system can be placed appear in the lower right graphic part of the screen, or sub-screen 1330. These areas of the vehicle are represented by rectangles 202, 204, 206 236, 240.
  • the user To add a zone, the user must first select the button 1312 place this rectangle, which corresponds to a new zone of the vehicle, by clicking in the sub-screen 1330.
  • the name 1342 of the product is included at the bottom of the sub-screen 1330. It is noted that the nodes and components defined for the design tool are included in the hierarchical list 1320. In fact, this hierarchical list is used once the different components are placed: selecting a particular node or computer makes it possible to locate in which zone of the vehicle it is placed, this zone automatically changing appearance in the 1330 sub-screen. For example, when in the hierarchical list, the pedal d is selected. acceleration 1321, the cockpit area 218 changes its appearance.
  • the components which have not yet been placed also have a particular appearance, such as the BVA node 1323 or the front wiper motor 1322.
  • an orientable compass 1344 for readability purposes for all of the users. It is up to the user to indicate which axes (left, right), (up, down), (front, back) should be used as well as their direction.
  • FIG. 13 in the case of a motor vehicle of which zones, seen from above, have been shown, the orientation allows the person skilled in the art to recognize some of these zones, such as, for example, flag 216, then step by step, all the areas represented. In order to make this division into zones more readable, it is possible to name the zones. This is for example the case of the right front wing named Aile AVD 1346.
  • FIG. 14 represents a local view of one of the zones of the vehicle represented in FIG. 13 in the sub-screen 1330 of the screen 1300. It is accessed, for example, by selecting the said zone in the sub-screen 1330 then by double clicking.
  • the dimensions of the said zone can be specified by selecting the button 1410 then by selecting one of the vertices of the said zone and moving it at will, the other vertices remaining unchanged. Selecting a point on the edge of the area other than a vertex allows you to define a new vertex.
  • You can specify an avoidance subzone by selecting a button 1412 and then the location of the zone where you want to place the avoidance subzone. The avoidance sub-area is then placed in the form of a rectangle with default dimensions.
  • the exact dimensioning of the subzone is then done, as for the vehicle zone, by selecting a button 1410 then by selecting one of the vertices of the selected avoidance subzone or by adding a vertex. By selecting a point on the contour other than a vertex.
  • the routing points are placed on the zone by first selecting a button 1414 then by selecting the place in the zone where it is desired to place said routing point.
  • the connection points of the zone are placed by first selecting the button 1416 then by selecting the place in the zone where it is desired to place said connection point.
  • a compass can be placed next to the area by selecting the button 1316, then oriented.
  • a recommended routing path can be set by selecting a 1418 button, then selecting a component or routing point or initial connection point, then selecting a component or routing point or final connection point.
  • the components and calculators are placed on the area by click-and-drag from the hierarchical list 1420. They can be associated with icons which make it possible to locate and recognize them more quickly.
  • the background screen can for example be made up of parallel and regular horizontal and vertical lines, cutting the space into blocks of 20mm by 20mm in the 1: 1 scale.
  • connection point placement operation has been carried out on different zones, one can return to the view presented in FIG. 13 to link the connection points of the different zones of the vehicle which correspond in the sub-screen 1330.
  • the connection points specified in the area 202 for example, appear.
  • This zone contains three connection points 1350, 1351, 1355.
  • Zone 220 contains, for the moment, a connection point 1353.
  • a graphic link 1354 is then automatically generated.
  • a new selection of the "View" menu 603, allows, if desired, to hide all the connection points and their links.
  • connection points it is possible to name the connection points, as is done for example for the connection point "C3" 1448.
  • the name of the connection point is shown in sub-screen 1330, when the option to display the names of connection points is activated.
  • FIG. 15 represents the screen which appears when the "Vehicle Z23" is selected and the "Func" tab 612 is selected.
  • a graph whose nodes are the service variants and the arrows the data flows exchanged between the service variants.
  • Such a flow of data represented by an arrow between a variant of departure service and a variant of arrival service is defined by the set of data produced by at least one elementary operation of the variant of departure service, which are not produced by no elementary operation of the variant of arrival service, but which are consumed by at least one elementary operation of the variant of service arrival.
  • the inter-service data flow as shown in FIG. 15 is generated for a choice of a service variant for each service corresponding to a configuration.
  • these data streams make it possible to identify the data for which precautions are to be taken during development.
  • the data between services and their characteristics must be validated for each service consuming or producing them, on the contrary, data intrinsic to a service, the development of which is solely the responsibility of said service.
  • FIG. 16 represents a screen appearing when the “HWD” tab 615 is selected, the “Network” tab 1232, and the UCH node 1621 in the hierarchical list 1220.
  • the graphic part 1630 a network view corresponding to the same conventions as the view described in graphic part 830 illustrated in FIG. 8. Only the networks on which the UCH node 1621 is present are then displayed, unlike what is represented in FIG. 8 where all the networks are displayed.
  • Tabs in an area 1640 make it possible to select the different networks of the architecture 1654, 1656, 1658. Selecting the "garlic" tab 1652 allows the display in the graphic part 1630 of all the networks and cancels the selection of node UCH 1621.
  • Steps 1712 and 1714 are syntheses carried out automatically for the tool while all the other steps are assisted by the ergonomics of the tool but are left to the initiative of the designer.
  • the use cases are specified, step 1702.
  • the operating phases are identified, the customer requests which are the transitions and the system responses which are the states, step 1704.
  • the phases are preferentially defined by their decomposition in transverse modes as this is presented in figure 7. Two phases preferentially do not share a combination of transverse modes.
  • a service control automaton is automatically synthesized for all the use cases of the service, step 1712.
  • stage 1716 the elementary operations carried out in each of the states of the service control automaton are specified, stage 1706.
  • step 1708 certain elementary operations carrying out the phase transitions are identified, step 1708, as well as the elementary operations carrying out the customer requests, step 1710.
  • the realization of a phase or state transition by an elementary operation is preferably represented by an elementary operation whose result is a boolean which when it is worth the boolean value "true" results in the activation of said transition.
  • boolean which when it is worth the boolean value "true" results in the activation of said transition.
  • steps 1706, 1708 and 1710 are partially or completely carried out, the data flow is synthesized between the elementary operations specified during these steps, step 1718.
  • step 1722 We can then synthesize a model of the specified service variant, step 1722, by completing in particular the automaton synthesized during step 1712 and the various elementary operations which are attached to it with the description of sensors and actuators preferably attached to the service and corresponding pilots.
  • FIG. 18 describes a method of designing electrical and electronic architecture making it possible to understand the interactions between the different stages of the method described in the invention, but also the different views proposed by the tool.
  • a specification of the product configurations is specified by the user, step 1802. It indicates the different configurations characterized in particular by a set of service variants and a set of computer variants. For each configuration, a percentage is indicated corresponding to the ratio of the number of products comprising said configuration by the total product number.
  • a specification of each service variant is carried out, step 1806, in particular by applying the method described in FIG. 17. It is then possible to automatically proceed to the validation of the service architecture, step 1808 (described below).
  • a set of configurations specified during step 1802, a set of nodes and the networks connecting them is specified and for each node a set of variants of computers, step 1810.
  • the geometry of the product is specified, step 1804.
  • the services can be placed on the different nodes, step 1812.
  • a messaging or the automatically generate, step 1826 for example using the method described in French patent application number 01-05713 of April 27, 2001 incorporated here by reference.
  • step 1810 the different computer variants, specified during step 1810, and the various sensors and actuators, in particular attached to the service variants, specified during step 1806, are placed on the geometric description of the vehicle, step 1814.
  • the routing points, connection points, connectors and avoidance zones are likewise placed, step 1820.
  • step 1814 From the placement of the various electrical and electronic components, step 1814, and from the description of the geometric constraints, step 1820, the routing of the signals, in particular of data, of power or linked to ground, step 1822, is synthesized.
  • the characteristics of the various elementary operations are specified in terms of code size, required RAM memory size and CPU consumption, step 1824.
  • a cost estimate of the system is deduced based on the cost of the electrical architecture (sensors, actuators, wires, connectors) and the cost linked to the types of inputs - outputs and to the choice of processors induced by the placement, step 1830.
  • This synthesis, step 1830 is carried out taking into account in particular the optimization induced by splices on the power and ground wires , step 1828.
  • the architecture evaluated can be compared with other architecture, in particular by a criterion of cost, of quality or weight, in particular by a cost criterion consolidating in particular the quality and weight criteria, step 1832.
  • a cost criterion consolidating in particular the quality and weight criteria
  • the service configuration is the selection of a set of service variants (optional or not).
  • the optional configuration services are those that are not always present.
  • the rate of rise of the optional services will be given, in particular in the form of a percentage.
  • the configurations are also used to make wiring choices, the example of air conditioning above shows this well since the wiring for a specific computer will have a different cost than the wiring for a non-optional computer.
  • the choice of an optimal electrical-electronic architecture is therefore preferably made as a function of a set of predefined configurations.
  • the configurations are also used to manage diversity by making it possible to limit by design the combinations of options available.
  • a component cannot be linked to an optional node such that there is at least one configuration where the node is absent and the component is present. Therefore in the search for the routing of said component, the nodes not satisfying the above criterion are not considered.
  • the cost calculation weighted by the rate of assembly of the different components is applied, that is to say that a component present in 40% of the configurations will have a cost weighted by 0.4. Routing that minimizes cost is economically optimal routing for all configurations.
  • the air conditioning compressor For example, you can attach the air conditioning compressor to the air conditioning node (optional and specifically installed for the air conditioning service) or to the passenger compartment computer node (always present).
  • the connection to the air conditioning node costs two euros including, for example, the cost of the computer connector for connection to the compressor and the other components, either one euro, the cost of the wires, one euro, and one euro on the passenger compartment controller. If the air conditioning rise rate exceeds 50%, then the compressor must be routed to the passenger compartment controller node, otherwise to the air conditioning node. For example, with an assembly rate of 40% and per hundred copies, routing to the passenger compartment node costs 1 * 100 * 1 euro is one hundred euros, while routing to the air conditioning node costs 0.40 * 100 * 2 euros is four- twenty euros.
  • a cost of mounting a strand necessary for the implementation of air conditioning in the cockpit area for example, - a cost of mounting a connector necessary for the implementation of air conditioning on a border in the cockpit area or in the cockpit area,
  • the option of routing on the air conditioning computer costs 120 euros + 0.4 * 100 * 1 + 1 * 100 * 2 is 360 euros, while the cost of routing on the passenger compartment computer is 150 euros + 1 * 100 * 2 is 350 euros.
  • the unit cost for replacing the computer is 100 * 200 / 1,000,000, ie 0.04 euros, to be increased by 0.01 euro for the air conditioning computer and 0.002 euros for the air conditioning computer.
  • the cost of repairing the wiring is 0.01 euro for a fault on all the wiring which is only present when the air conditioning option is selected.
  • Our consolidated unit cost including quality defects is therefore now 360 + 0.4 * 100 * ((0.04 + 0.01) (calculator) + 0.01 (wiring)) euros or 362.4 euros while the scenario with passenger compartment computer now costs 350 + 0.4 * 100 * 0.01 or 350.4 euros if we take into account the fact that the quality costs linked to the passenger compartment calculator are identical in both scenarios and that the air conditioning specific wiring is only fitted when the air conditioning option is selected.
  • the number of ppm of the scenario with air conditioning calculator is 0.4 * (100 + 100) or 80 ppm while the number of ppm of the scenario without air conditioning calculator is 0.4 * 100 or 40 ppm if we ignore the ppm linked to the constant cabin computer in the two scenarios. In terms of quality, the scenario without an air conditioning computer is therefore preferable.
  • the weight of the scenario with air conditioning calculator is 0.4 (rate of rise) * 0.4 (kilos) or 160 grams while the weight of the option without air conditioning calculator is 0.4 (rate of clim clim) * 0.3 (300 grams) + 0.6 (without clim) * 0.150 (weight of the calculator surplus) or a marginal weight of 129 grams and it is the latter wiring that is optimal in weight.
  • the system architecture design tool described above allows for a plurality of validations throughout the design process.
  • - functional validation which consists in verifying that any data consumed by an elementary operation must be produced by an elementary operation independently of the link of the elementary operations to the different services. This step can be carried out once the functional architecture has been completed in the REQ and FUNC windows accessible by the 611 and 612 tabs.
  • Functional validation after placement which consists in verifying that any data consumed by an elementary operation must be produced by an elementary operation and moreover, that between the producer and the consumer, there exists a path possibly made up of networks and intermediate nodes. This step can be carried out once the services have been completely or partially placed in the MAP window accessible via the 613 tab.
  • Functional validation and messaging which consists in verifying that any data consumed by an elementary operation must be produced by an elementary operation and that in addition, between the producer and the consumer, there is a path possibly made up of networks and intermediate nodes and moreover, for at least one path, locations in frames are provided for the routing of the data from the producer to the consumer. This step can be carried out when the data frames have been partially or completely carried out using the windows
  • HWD and MSG accessible via tabs 615 and 616.
  • the validation of the service architecture by configuration and / or by mode which consists in applying the three previous validations on the one hand for each configuration of the product and on the other hand for each transverse mode of the product.
  • validations are accessible by a user menu (not shown) accessible by clicking on the Tools 606 tab shown in particular in Figure 6.
  • a user menu accessible by clicking on the Tools 606 tab shown in particular in Figure 6.
  • CRASH "In a running engine context, if a crash is detected, then the vehicle must be unlocked urgently".
  • a "crash detected" request is specified. It is carried out by an elementary operation which captures the value given by an accelerometer "A”. This value is "a”.
  • the acceleration capture software driver corresponds to program "P1".
  • the state of arrival of the CRASH use case is for example a state which we will name "Emergency unlocking”.
  • the elementary operation "unlocking the doors” is carried out. It corresponds to a datum set to 1 which controls by a software driver P2 which controls the locks of the doors Vi. If we give a performance constraint of 100ms on the realization of the CRASH use case this means:
  • That the accelerometer has detected a crash value a. - that the value of aa has been refreshed by executing the pilot P1 that entry into the state of emergency unlocking has been carried out that the data has been set to 1 that the software P2 has been executed that the locks Vi have operated on everything in less than 100 ms.
  • the accelerometer is placed on an airbag computer and the lock control is placed on another computer, for example the passenger compartment computer, and these two computers are connected by a CAN bus on which the data has is transported by a T frame.
  • the constraint of 100 ms now means:
  • the accelerometer has detected a crash value a. that the value of aa has been refreshed by executing the pilot P1 that the value of aa has been written in the CAN pilot of the Airbag computer for remission of the T frame - that the T frame has circulated on the bus that the T frame has been read and the value of a extracted by the CAN pilot from the passenger compartment computer that the entry into the Emergency unlocking state was carried out that the data was set to 1 - that the software P2 was executed that the latches Vi worked all in less than 100ms. From this list we establish performance requirements for the execution of each of these steps.
  • the frame T be transmitted every 20 ms, which leaves 80 ms of execution time for the other operations which are sequentially executed before or after the transmission of the frame. If this assumption turns out to be too difficult to hold, we will reduce the transmission time from T to 10 ms for example. If, on the contrary, we notice that the network through which T transits is very busy, we will try to issue a transmission requirement every 30 ms for T and we will try to carry out all the operations which must take place before or after the emission of T in less than 70ms. Conversely, if performance requirements have been expressed on these various operations, we can verify that the sum of these operations is done in less than 100ms.
  • a 2-D topology is not a prerequisite.
  • a 2-D topology is a result of the method of the present invention and therefore can be used for example as an input to such systems. Also, according to the present invention, the paths are generated automatically.
  • top-down by following the tabs, in order, as described in the description, and "bottom-up”, that is to say by following any specification order desired by the designer, including selecting the tabs in the reverse order of what is described in the description.
  • procedure of the present invention can be performed in the form of a computer program and saved to the memory of a computer. Manufactured articles may be produced on which such computer programs may be recorded.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Geometry (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Computational Mathematics (AREA)
  • Game Theory and Decision Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Stored Programmes (AREA)
  • Programmable Controllers (AREA)
  • Wire Bonding (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention fournit un procédé de conception d’une spécification d’un système matériel et logiciel, caractérisé en ce qu’il comporte : -une étape de définition de prestations et, pour chaque prestation , de cas d’utilisation ; -une étape d’association de chaque cas d’utilisation à au moins un état de départ du système, une demande utilisateur et, pour chaque état de départ, un état d’arrivée du système ; -une étape de définition d’opérations au cours de laquelle, pour chaque état on définit un ensemble d’opérations élémentaires correspondant à la réponse du système lors de l’arrivée dans ledit état ; -une étape de spécification d’architecture du système définissant des unités de contrôle électronique et des réseaux ; -une étape de placement des opérations élémentaires sur les calculateurs ; et, au moins l’une des étapes suivantes : -une étape d’identification des flots de données circulant sur lesdits réseaux en fonction dudit placement ; et -une étape d’identification de la spécification des interfaces des calculateurs en fonction dudit placement.

Description

PROCEDE ET DISPOSITIF POUR SYNTHETISER UNE ARCHITECTURE
ELECTRIQUE La présente invention concerne un procédé et un dispositif pour synthétiser une architecture électrique et les applications de ce procédé à un véhicule, et en particulier un procédé et dispositif de conception d'une spécification d'un système matériel et logiciel.
Il existe aujourd'hui de nombreux procédés et dispositifs qui traitent isolément de la gestion d'exigence, de la spécification de fonctions électroniques, de la conception de calculateurs de contrôle électronique, de la conception de messageries pour des réseaux embarqués, de la conception de logiciel, mais aucun procédé ou dispositif ne couvre l'ensemble de ces aspects en vue de permettre une conception rapide de systèmes matériel et logiciel distribué.
La présente invention à pour but de fournir un procédé et un dispositif améliorés pour synthétiser une architecture électrique et les applications de ce procédé à un véhicule, et en particulier de fournir un procédé et un dispositif améliorés de conception d'une spécification d'un système matériel et logiciel.
Selon un premier aspect, la présente invention vise un outil de conception d'architecture de système, caractérisé en ce qu'il comporte plusieurs écrans qui comportent, chacun :
- une description hiérarchisée du système, au moins un des niveaux de la hiérarchie représentant des prestations offertes à des utilisateurs, et
- lorsqu'un élément de la description hiérarchisée est sélectionné, une vue synthétique d'une partie au moins de l'interface de cet élément avec le reste du système.
La présente invention fourni un procédé de conception d'une spécification d'un système matériel et logiciel, caractérisé en ce qu'il comporte : - une étape de définition de prestations et, pour chaque prestation, de cas d'utilisation ;
- une étape d'association de chaque cas d'utilisation à au moins un état de départ du système, une demande utilisateur et, pour chaque état de départ, un état d'arrivée du système ;
- une étape de définition d'opérations au cours de laquelle, pour chaque état, on définit un ensemble d'opérations élémentaires correspondant à la réponse du système lors de l'arrivée dans ledit état ;
- une étape de spécification d'architecture du système définissant des unités de contrôle électronique et des réseaux ;
- une étape de placement des opérations élémentaires sur les calculateurs ; et, au moins l'une des étapes suivantes :
- une étape d'identification des flots de données circulant sur lesdits réseaux en fonction dudit placement ; et - une étape d'identification de la spécification des interfaces des calculateurs en fonction dudit placement.
Il sera apprécié que la procédure de conception peut comprendre la production de copie de données, comme par exemple des données qui peuvent être lues par une machine pour la mise en oeuvre automatique d'une étape de fabrication ou d'essai de systèmes, ou par une personne pour contrôler un tel système.
Grâce à ces dispositions, il est possible de prendre directement en compte les prestations offertes aux clients en y accédant dans lesdits écrans et en observant des vues synthétiques liées à ces prestations. On rappelle ici que les prestations représentent des services au bénéfice d'un utilisateur du système, par exemple le conducteur d'un véhicule embarquant ledit système. Des prestations sont définies par ce que l'utilisateur veut (par exemple la mise en route de la climatisation, d'essuie-glaces) ou par ce qu'on lui propose (par exemple une sécurité passive, notamment en cas d'accidents). Elles sont aussi définies par des capteurs et/ou des actionneurs qu'elles mettent en oeuvre. Elles correspondent, chacune, à une réalisation matérielle capteur/logiciel/actionneur, le capteur pouvant être matériel (capteurs en tableau de bord ou pédales, par exemple). A partir des prestations, l'outil de conception permet de déterminer des spécifications du système, des interfaces et ce que doivent comporter les éléments du système et leur communication avec les autres éléments du système. Selon des caractéristiques particulières, l'outil comporte un moyen de sélection, appelé "onglet", d'une description hiérarchisée, la sélection de chaque onglet faisant apparaître un écran différent de l'outil.
Grâce à ces dispositions, le passage d'un écran à l'autre est particulièrement aisé. Selon des caractéristiques particulières, pour au moins un écran, la description hiérarchisée représente, à un premier niveau de hiérarchie, une pluralité de prestations, et à un deuxième niveau de hiérarchie, une pluralité de cas d'utilisation pour chaque prestation.
Grâce à ces dispositions, chaque prestation est définie par les cas de son utilisation. Par exemple, la prestation "essuie-glaces" peut être définie par des cas d'utilisation de balayage alterné, de balayage lent et de balayage rapide. Selon des caractéristiques particulières, pour au moins un dit écran, chaque cas d'utilisation comporte un contexte ou situation initiale du système, une demande d'un utilisateur au système et une réponse du système correspondant à un changement de son état.
Grâce à ces dispositions, on disposera des informations nécessaires pour réaliser les tests d'intégration de la prestation.
Selon des caractéristiques particulières, dans au moins un écran, pour chaque cas d'utilisation d'une prestation, on définit des états et des transitions d'état associées. Grâce à chacune de ces dispositions, les cas d'utilisation sont formalisés et en relation directe avec les situations et états du système et les demandes de l'utilisateur du système qui définissent les transitions entre états.
Selon des caractéristiques particulières, avec au moins un écran, on regroupe les états qui fonctionnent dans des modes transverses aux prestations communs, dans des "phases", chaque état est associé à une phase du système, l'ensemble des cas d'utilisation formalisés représentant toutes les réponses ou absences de réponse du système dans toutes les phases, celles ci représentant, ensemble, toutes les combinaisons des modes de fonctionnement du véhicule. Grâce à ces dispositions, on hiérarchise les états ce qui permet une meilleure lisibilité car on peut considérer chaque phase séparément, puis chaque transition de phase. Selon des caractéristiques particulières, chaque phase est constituée d'un ensemble de combinaison des modes de fonctionnement du véhicule, les modes étant transversaux aux prestations et hors du contrôle direct des prestations, par exemple un mode représentant un niveau d'énergie disponible et/ou un type d'utilisateur du système et ou un état accidenté ou non d'un véhicule.
Grâce à ces dispositions, la définition des phases est normalisée et de mise en oeuvre aisée, elle permet d'autre part une lecture facilitée car hiérarchisée des états.
Selon des caractéristiques particulières, pour au moins un écran, la description hiérarchisée représente, à un premier niveau de hiérarchie, une pluralité de prestations, et à un deuxième niveau de hiérarchie, des phases de la prestation.
Grâce à ces dispositions, la description des prestations est détaillée pour chacune des phases du système, ce qui simplifie le travail de l'utilisateur de l'outil.
Selon des caractéristiques particulières, pour au moins un écran, la description hiérarchisée représente, à un premier niveau de hiérarchie, une pluralité de prestations, et à un deuxième niveau de hiérarchie, des états.
Grâce à ces dispositions, la description des prestations est rattachée à des états du système, ce qui simplifie le travail de l'utilisateur de l'outil.
Selon des caractéristiques particulières, dans la description hiérarchisée, un niveau hiérarchique décrit, dans un état donné, les opérations élémentaires.
Grâce à ces dispositions, les opérations élémentaires effectuées par le système sont accessibles dans la description hiérarchisée et peuvent être éditées par l'utilisateur de l'outil.
Selon des caractéristiques particulières, pour au moins un écran, un utilisateur peut effectuer un placement d'opérations élémentaires sur des composants représentés sur une vue synthétique. Grâce à ces dispositions, les aspects fonctionnels du système peuvent être implantés sur les composants matériels de ce système.
Selon des caractéristiques particulières, l'outil comporte, pour au moins un écran, une vue synthétique représentant une enveloppe d'un composant et chaque opération élémentaire que ledit composant contrôle ou commande.
Grâce à ces dispositions, l'utilisateur de l'outil peut étudier le fonctionnement de chaque composant et les spécifications qui en découlent.
Selon des caractéristiques particulières, l'outil comporte, pour au moins un écran, une vue synthétique représentant une enveloppe d'une prestation et chaque opération élémentaire que ladite prestation comporte.
Grâce à ces dispositions, l'utilisateur de l'outil peut étudier le fonctionnement de chaque prestation et les spécifications qui en découlent.
Selon des caractéristiques particulières, pour au moins un écran, la description hiérarchisée représente des calculateurs du système, à un premier niveau de hiérarchie, et à un deuxième niveau de hiérarchie, des opérations élémentaires contrôlées ou commandées électroniquement par chaque calculateur.
Grâce à ces dispositions, l'utilisateur de l'outil peut étudier le fonctionnement de chaque calculateur et les spécifications qui en découlent.
Selon des caractéristiques particulières, pour au moins un écran, une vue synthétique représente, pour chaque calculateur, les prestations qui sont, au moins partiellement, placées sur ledit calculateur.
Grâce à ces dispositions, l'utilisateur de l'outil peut étudier les relations entre les prestations et les calculateurs.
Selon des caractéristiques particulières, pour au moins un écran, une vue synthétique représente, pour chaque calculateur, les modes dans lesquels ledit calculateur doit fonctionner.
Grâce à ces dispositions, l'utilisateur de l'outil peut étudier les relations entre les modes et les calculateurs.
Selon des caractéristiques particulières, pour au moins un écran, une vue synthétique représente au moins un réseau et les composants qui y sont reliés.
Grâce à ces dispositions, l'utilisateur peut étudier le fonctionnement de chaque réseau.
Selon des caractéristiques particulières, pour au moins un écran, la description hiérarchisée représente des calculateurs du système, à un premier niveau de hiérarchie, et à un deuxième niveau de hiérarchie, pour chaque calculateur, les trames de données transitant sur les bus auxquels est connecté le calculateur et/ou les composants électroniques (capteurs, actionneurs) directement connectés au calculateur. Grâce à ces dispositions, l'utilisateur de l'outil peut étudier chaque calculateur et les interactions qu'il a avec d'autres éléments du système, en particulier les bus auxquels il est connecté.
Selon des caractéristiques particulières, pour au moins un écran, la description hiérarchisée représente des trames, à un premier niveau de hiérarchie, et à un deuxième niveau de hiérarchie, pour chaque trame, les données contenues dans les trames.
Grâce à ces dispositions, l'utilisateur de l'outil peut détailler la messagerie utilisée et établir les relations entre les trames et les données qu'elles contiennent.
Selon des caractéristiques particulières, pour au moins un écran, une vue synthétique représente des composants et/ou réseaux et une projection d'une prestation sur lesdits composants et/ou réseaux.
Grâce à ces dispositions, l'utilisateur de l'outil peut étudier séparément chaque prestation, en terme d'implantation matérielle.
Selon des caractéristiques particulières, pour au moins un écran, un niveau hiérarchique décrit, pour chaque opération élémentaire, les flots de données d'entrée et de sortie d'interface, pour chaque flot de données, le pilote et le composant et/ou l'opération élémentaire, avec lequel le flot de données est échangé.
Grâce à ces dispositions, l'utilisateur de l'outil peut étudier le détail de la mise en oeuvre d'une opération élémentaire, en termes de flots de données, de pilotes et/ou de composants.
Selon des caractéristiques particulières, pour au moins un écran, la description hiérarchisée représente, à un premier niveau de hiérarchie, une pluralité de prestations, et à un deuxième niveau de hiérarchie, une pluralité de variantes de prestation, pour chaque prestation. Grâce à ces dispositions, l'outil permet de traiter différentes variantes d'une prestation dans la conception de l'architecture d'un système.
Selon des caractéristiques particulières, pour au moins un écran, la description hiérarchisée représente, à un premier niveau de hiérarchie, une pluralité de composants électroniques, et à un deuxième niveau de hiérarchie, une pluralité de variantes de composants électroniques, pour chaque composant électronique.
Grâce à ces dispositions, l'outil permet de traiter différentes variantes d'un composant, par exemple différents composants de différents équipementiers, dans la conception de l'architecture d'un système.
Selon des caractéristiques particulières, pour au moins une vue synthétique, une sélection, avec un dispositif de pointage, d'un élément de la vue synthétique donne accès à une représentation de fonctionnement dudit élément. Grâce à ces dispositions, l'utilisateur de l'outil peut étudier le fonctionnement des différents éléments représentés dans la vue synthétique.
Selon des caractéristiques particulières, pour un cas d'utilisation, étant donné un placement partiel ou complet des prestations, on identifie automatiquement l'ensemble des opérations élémentaires dans l'architecture ainsi que l'ensemble des données échangées (trames, capteurs, actionneurs) correspondant à la réalisation du cas d'utilisation.
Grâce à ces dispositions, si une erreur est observée, lors d'un test d'intégration, c'est à dire pour un cas d'utilisation donné, on peut retrouver les composants susceptibles d'être à l'origine du défaut. Selon des caractéristiques particulières, pour un cas d'utilisation, si on exprime une contrainte de performance sur ledit cas d'utilisation, on identifie automatiquement l'ensemble des opérations élémentaires dans l'architecture, l'ensemble des trames échangées, l'ensemble des capteurs nécessaires et/ou l'ensemble des actionneurs activés, de manière à leur affecter respectivement des contraintes de délai d'exécution, de délai de transmission, de délai d'activation propres et/ou valider des contraintes déjà exprimées.
Grâce à ces dispositions, on va pouvoir décider des contraintes de rafraîchissement des différentes données échangées par des opérations élémentaires auxquelles s'applique la contrainte de performance.
La présente invention vise, selon un deuxième aspect, un procédé pour synthétiser une architecture électrique et électronique d'au moins une partie d'un produit comprenant des fils électriques et des composants électriques et électroniques tels que des capteurs, des actionneurs et des calculateurs, caractérisé en ce qu'il comporte les étapes suivantes :
- on représente en deux dimensions la géométrie du produit découpée en différentes zones ; - on place dans les différentes zones, des points de routage pour le routage des fils électriques ;
- on place entre les différentes zones des points de connexion ;
- on place les composants électriques et électroniques dans les zones ;
- on procède à une synthèse du routage en fonction de la géométrie des différentes zones, des positions des points de routage, des points de connexion et des composants ;
- on procède à une évaluation de ce routage et en fonction du résultat de cette évaluation ;
- on modifie des emplacements de points de routage, de points de connexion et/ou de composants électriques et électroniques et on répète les étapes de synthèse et d'évaluation. Dans la présente invention, une topologie 2-D est un résultat du procédé. Aussi, selon la présente invention, les chemins sont générés automatiquement. Grâce à ces dispositions, on optimise le routage par itération.
Selon des caractéristiques particulières, au moins un point de connexion correspond, dans le produit, à un connecteur et/ou au moins un point de routage correspond, dans le produit, à un connecteur.
Grâce à ces dispositions, on prend en compte et on dimensionne les connecteurs. Selon des caractéristiques particulières, on précise à l'intérieur desdites zones, des sous-zones d'évitement dans lesquelles aucun fil, composant ou connecteur ne doit être placé et, au cours de l'étape de synthèse, on interdit qu'un fil traverse une sous-zone d'évitement.
Grâce à ces dispositions, la représentation est plus fidèle et tient compte de l'encombrement de certaines zones du produit.
Selon des caractéristiques particulières, avant de placer les composants électriques et électroniques, on fait au moins un des choix ci-après :
- choix d'unités de contrôle électroniques,
- choix de réseaux de communication,
- choix de capteurs et actionneurs,
- choix de boîtiers fusibles et relais, - choix d'une architecture électrique et électronique.
Selon des caractéristiques particulières, avant de procéder à la synthèse du routage, on spécifie des caractéristiques des composants électriques et électroniques.
Selon des caractéristiques particulières, après la synthèse du routage, on visualise le câblage constitué du routage synthétisé et de connecteurs. Grâce à ces dispositions, on peut mettre au point le placement des points de routage en simplifiant la géométrie des torons.
Selon des caractéristiques particulières, le procédé comporte une étape de validation d'un routage parmi ceux évalués, et on procède au calcul d'une spécification technique du câblage constitué du routage synthétisé validé et de connecteurs et on procède à la suite du calcul de la spécification technique, au calcul d'un coût du câblage et/ou au calcul d'une mesure de qualité, par exemple par l'estimation du nombre de pannes par million et par an du câblage.
Grâce à ces dispositions, le concepteur peut comparer différentes solutions d'architecture et transmettre la spécification de l'architecture retenue à l'équipe de développement et de mise au point. Selon des caractéristiques particulières, le produit est un véhicule et les différentes zones du véhicule comprennent au moins l'une des zones suivantes :
- la zone de la face avant,
- la zone du capot, - la zone du tableau de bord,
- la zone du pavillon,
- la zone du coffre et du hayon, au-dessus et en dessous des zones ci-dessus,
- la zone de l'aile avant droite et de l'aile avant gauche, - la zone de la porte avant droite et de la porte avant gauche,
- la zone du montant droit et du montant gauche,
- la zone de la porte arrière droite et de la porte arrière gauche,
- la zone de l'aile arrière droite et de l'aile arrière gauche, entre la zone du tableau de bord et celles de l'aile avant droite et de l'aile avant gauche, les zones du montant avant droite et du montant avant gauche, entre la zone du coffre et celles de l'aile arrière droite et de l'aile arrière gauche, les zones du montant arrière droit et du montant arrière gauche,
- une zone du dessus de plancher et une zone du dessous de plancher. Grâce à ces dispositions, on peut appliquer le procédé à un véhicule automobile.
Selon un troisième aspect, la présente invention vise un outil de conception d'architecture de système, caractérisé en ce qu'il comporte, pour des objets, composants matériels et/ou prestations offertes au client, une représentation graphique dite "enveloppe" qui comporte : - un contour représentant ledit objet,
- des représentations d'autres objets avec lequel ledit objet communique, et
- des représentations de données échangées avec lesdits autres objets.
Grâce à ces dispositions, l'utilisateur de l'outil dispose d'une vue synthétique de l'interaction de l'objet avec d'autres objets du système. Selon des caractéristiques particulières, lorsque ladite enveloppe représente un composant matériels, des représentations de données sont effectuées pour une prestation.
Grâce à ces dispositions, chaque couple composant matériel - prestation peut être étudié séparément.
Selon un quatrième aspect, la présente invention vise un outil de représentation de système comportant des composants électroniques reliés, chacun, à au moins un bus, caractérisé en ce qu'il comporte, pour chaque bus, une représentation des composants qui y sont directement reliés et, pour les composants directement reliés à au moins deux bus, pour chacun de ces bus, associé audit composant, un identificateur de chaque autre bus auquel ledit composant est directement relié.
Grâce à ces dispositions, l'utilisateur de l'outil dispose d'une vue en trois dimensions, sans complexité de représentation, chaque bus étant représenté en deux dimensions et les liens entre les bus étant représentés, selon une troisième dimension, grâce aux identificateurs.
Selon des caractéristiques particulières, ledit identificateur est un élément graphique, par exemple une pastille d'une couleur identique à celle du bus dans ladite représentation.
Grâce à ces dispositions, la visualisation des relations entre les bus est aisée, grâce à la visualisation de l'élément graphique.
Selon un cinquième aspect, la présente invention vise un procédé de conception d'une spécification d'un système matériel et logiciel, caractérisé en ce qu'il comporte : - une étape de définition de prestations et, pour chaque prestation, de cas d'utilisation ;
- une étape d'association de chaque cas d'utilisation à au moins un état de départ du système, une demande utilisateur et, pour chaque état de départ, un état d'arrivée du système ; - une étape de définition d'opérations au cours de laquelle, pour chaque état, on définit un ensemble d'opérations élémentaires correspondant à la réponse du système lors de l'arrivée dans ledit état ;
- une étape de spécification d'architecture du système définissant des unités de contrôle électronique et des réseaux ; - une étape de placement des opérations élémentaires sur les calculateurs ; et, au moins l'une des étapes suivantes :
- une étape d'identification des flots de données circulant sur lesdits réseaux en fonction dudit placement ; et
- une étape d'identification de la spécification des interfaces des calculateurs en fonction dudit placement.
Grâce à ces dispositions, ce procédé permet de partir des prestations offertes à l'utilisateur du système, de déterminer le fonctionnement du système puis d'implanter les opérations élémentaires mettant en oeuvre les prestations sur des calculateurs et d'identifier les conséquences de l'implantation en termes de flots de données et/ou en termes de spécification d'interfaces.
Selon des caractéristiques particulières, l'étape de placement comporte, pour chaque prestation, un choix parmi plusieurs modes de placement comportant notamment : - le placement de la prestation sur un seul calculateur,
- le placement maître-esclave dans lequel une opération élémentaire supplémentaire de contrôle de la prestation unique, active, suivant l'état de la prestation dans lequel se trouve le système, les opérations élémentaires de la prestation, cette opération élémentaire supplémentaire étant placée sur l'un des calculateurs,
- le placement distribuée dans lequel les opérations élémentaires sont réparties sur au moins deux calculateurs et, sur chacun desdits calculateurs, une opération élémentaire supplémentaire de contrôle de la prestation est placée et active, suivant l'état de la prestation dans lequel se trouve le système, les opérations élémentaires de la prestation placées sur ledit calculateur.
Grâce à ces dispositions, le placement de chaque prestation peut être effectué sur un ou plusieurs composants, avec des opérations élémentaires de contrôle correspondantes.
Selon des caractéristiques particulières, les opérations élémentaires supplémentaires sont générées automatiquement avec :
- comme entrées, toutes les données nécessaires au calcul des transitions de l'automate de contrôle de la prestation dont les états sont les états de la prestation et les transitions les traductions, par une opération élémentaire, des demandes utilisateur et
- comme sortie, une donnée représentant l'état dans lequel se trouve la prestation. Grâce à ces dispositions, le travail de l'utilisateur de l'outil est très simplifié.
Selon des caractéristiques particulières, au cours de l'étape d'identification des flots de données, on détermine un état de chaque flot de données, par rapport à une messagerie donnée :
- données "libres", à placer dans des trames, - données déjà placées dans une trame et circulant sur le réseau et telles qu'elles sont produites dans les calculateurs où la trame est produite et consommée dans les calculateurs où la trame est consommée, et
- emplacements de trame non utilisés.
Grâce à ces dispositions, les données et les trames peuvent être organisées, et pendant la conception du système, on peut mesurer le travail restant à faire pour couvrir l'ensemble des échanges de données par les différentes trames.
Selon des caractéristiques particulières, étant donné un cas d'utilisation, on exprime une contrainte de performance sur ce cas d'utilisation ainsi que sur certaines des opérations élémentaires réalisées dans l'état d'arrivée dudit cas d'utilisation, l'outil synthétise alors automatiquement la liste des exécutions d'opérations élémentaires, exécutions de pilotes, écritures et lectures dans des trames, prise en compte d'information par des capteur et des actionneurs, transfert de trame sur un réseau mise en oeuvres suite au placement desdites opérations élémentaires et le concepteur peut valider que cette contrainte de performance est satisfaite pour un placement desdites opérations élémentaires ou spécifier des exigences de délai d'exécution et/ou de temps de réponse pour satisfaire cette contrainte de performance. Grâce à ces dispositions, on peut s'assurer que le système aura bien les performances attendues et l'on peut notamment mettre au point des exigences de performance pour les divers composantes du système.
Selon des caractéristiques particulières, si, pour une prestation possédant au moins deux variantes, lesdites variantes ont des opérations élémentaires partagées, alors lesdites opérations élémentaires sont placées sur les mêmes calculateurs ou variantes de calculateur.
Par exemple des variantes d'accès au véhicule, l'une avec clé, l'autre sans clé, partagerons les opérations élémentaires de verrouillage et déverrouillage.
Grâce à ces dispositions, il est possible de gérer simplement la diversité des prestations lors de l'étape de placement car l'on a pas besoin d'effectuer plusieurs fois le placement d'une opération élémentaire partagée entre plusieurs variantes de prestation.
Selon un sixième aspect, la présente invention vise un outil de conception d'un plan de câblage, caractérisé en ce qu'il comporte plusieurs écrans qui comportent chacun : - une description hiérarchisée des composants matériels à placer - une représentation en deux dimensions des zones sur lesquelles les composants sont placés.
Selon des caractéristiques particulières, la représentation en deux dimensions des zones sur lesquelles les composants sont placés comporte une vue globale de l'ensemble des zones ainsi qu'un moyen de rajouter ou enlever des zones. Selon des caractéristiques particulières, lorsque l'on sélectionne une zone dans la vue globale de l'ensemble des zones, une vue locale de la zone, vue locale dans laquelle des caractéristiques géométriques de la zone peuvent être spécifiées, par exemple en cliquant déplaçant des points de contour de la zone, apparaît.
Grâce à ces dispositions, la spécification de la zone peut être fidèle à la pièce qu'elle représente.
Selon des caractéristiques particulières, on peut éditer, sur la vue locale d'une zone en cliquant-déplaçant à partir d'une icône de l'outil, des points de routage, des points de connexion, des sous-zones d'évitement et ou des points de masse.
Grâce à ces dispositions, le concepteur peut spécifier des points de passage préférentiels pour le routage des fils qui permettront de former des torons, des points de passage préférentiels d'une zone à une autre et des sous-zones d'évitement dans lesquelles aucun fil ne peut passer par exemple pour des raisons mécaniques ou d'encombrement, les endroits de la zone qui peuvent servir de masse.
Selon des caractéristiques particulières, un point de routage ou un point de connexion entre zone peut être transformé en connecteur en cliquant sur un attribut dudit point de routage ou de connexion.
Grâce à ces dispositions, on peut spécifier l'emplacement des connecteurs qui permettront de découper les fils et torons en pièces suffisamment petites ou pratiques pour le montage.
Selon des caractéristiques particulières, on peut spécifier l'emplacement des différents composants électroniques, les boîtiers fusibles et relais, les unités de contrôle électroniques, les capteurs, les actionneurs, notamment en cliquant déplaçant sur une représentation desdits composants dans une liste hiérarchisée.
Grâce à ces dispositions, le concepteur peut spécifier l'emplacement où seront placés ces composants sur les différentes zones du produit. Selon des caractéristiques particulières, on synthétise automatiquement le routage des différents capteurs et actionneurs jusqu'aux différents boîtiers fusibles et relais et unités de contrôle électronique.
Grâce à ces dispositions, on peut visualiser le câblage et mettre au point le positionnement des points de routage et de connexion pour réduire "à vue" les longueurs et les formes des torons.
Selon des caractéristiques particulières, pour chaque capteur et chaque actionneur, des pines de données associées à des pilotes (matériels et logiciels) eux-mêmes associés à des données, des pines de puissance correspondant à l'alimentation et des pines de masse étant spécifiées, on synthétise automatiquement, le routage des fils correspondant à ces fils aux unités de contrôle électroniques ou aux boîtiers fusibles et relais pour les données, aux boîtiers fusibles relais pour les fils de puissance et aux masses respectivement les plus proches.
Grâce à ces dispositions, on évalue le nombre de pines des connecteurs, des connecteurs des unités de contrôle électroniques et des boîtiers fusibles et relais, ainsi que la taille des différents torons.
Selon des caractéristiques particulières, si un capteur ou un actionneur est relié à un calculateur dans l'outil de conception d'architecture de système, alors, au cours de la synthèse du routage, on relie les pines de données dudit capteur ou dudit actionneur au dit calculateur. Grâce à ces dispositions, des exigences de liaison d'un capteur ou d'un actionneur à un calculateur, par exemple pour des raisons contractuelles avec un fournisseur, sont prises en compte dans la conception de l'architecture électrique et électronique. Selon des caractéristiques particulières,
- étant donnée une fonction de coût des connecteurs, par exemple basée sur un abaque qui donne une estimation du prix des connecteurs en fonction du nombres de connexions de données, de puissance et de masse, ou basé par exemple sur un prix moyen affecté à chaque connexion d'un fil de données, courant ou masse,
- étant donnée une évaluation du coût des composants électroniques, capteurs, actionneurs, unités de contrôle électronique ou boîtiers fusibles et relais - étant donnée une fonction de coût des fils basée par exemple sur leur longueur et sur leur type, en prenant par exemple un poids linéaire moyen pour les fils de puissance et de masse, un poids linéaire moyen pour les fils de données, et un coût massique du composant dans lequel sont fabriqués lesdits fils, on calcule automatiquement un coût d'une architecture électrique et électronique, en fonction d'au moins une desdites fonctions et évaluations.
Grâce à ces dispositions, on peut comparer les coûts respectifs de deux architectures afin de choisir la moins chère.
Selon des caractéristiques particulières, étant donné un coût moyen pour les pilotes logiciels et matériels des différents pilotes, étant donné un coût de mise en oeuvre d'une opération élémentaire, on estime automatiquement un coût d'une unité de contrôle électronique ou d'un boîtier fusibles et relais puis d'une architecture électrique et électronique complète.
Grâce à ces dispositions, l'estimation de coût est automatique à partir de n'importe quel placement réalisé dans l'outil de conception d'architecture de système d'une pluralité de prestations pour lesquelles des estimations ont été réalisées.
Selon des caractéristiques particulières, étant donné un routage synthétisé, étant données des mesures de qualité pour les connecteurs et les portions de fil des différentes zones, on estime automatiquement une mesure de qualité d'une architecture électrique et électronique.
Grâce à ces dispositions, on peut évaluer la qualité respective de deux architectures électriques.
Selon des caractéristiques particulières, étant donné une mesure de qualité des différents calculateurs capteurs et actionneurs placés dans les différentes zones, on estime automatiquement la qualité d'une architecture électrique et électronique Grâce à ces dispositions, on peut évaluer la qualité respective de deux architectures électriques et électroniques
Selon des caractéristiques particulières,
- étant donné une mesure de qualité pour chaque type d'entrées/sorties, pour chaque type de fil (puissance, masse, données),
- étant donnée une mesure de qualité pour l'exécution d'une instruction sur un calculateur, pour un accès en mémoire vive, pour un accès en mémoire flash, on calcule automatiquement une mesure de qualité pour l'exécution d'une opération élémentaire, et pour l'exécution d'un ensemble d'opérations élémentaires sur un calculateur. Grâce à ces dispositions, on prend en compte précisément la qualité de fonctionnement des calculateurs dans l'évaluation qualité d'une l'architecture électrique électronique.
Selon des caractéristiques particulières, on détermine automatiquement, dans chaque zone, des points de routage candidats pour regrouper les fils de puissance et de masse en épissures et l'on choisit automatiquement celui qui minimise la longueur de fil dans ladite zone.
Grâce à ces dispositions, on optimise la longueur du câblage et on minimise la taille des connecteurs. Selon des caractéristiques particulières, on tient compte des épissures dans les évaluations de coût et de qualité.
Grâce à ces dispositions, ces évaluations sont de meilleure qualité. Selon un septième aspect, la présente invention vise un outil de synthèse d'un routage économiquement optimal, caractérisé en ce que : - les différentes configurations de variantes de prestation et de variantes de calculateurs étant spécifiées et le taux d'occurrence de ces configurations étant connu, la somme des taux des configurations étant égale à un,
- les caractéristiques de coût des composants étant connues et pondérées en fonction de leurs taux de monte respectifs, - le placement partiel ou complet des variantes de prestation sur les variantes de calculateur étant réalisé, on synthétise automatiquement un routage économiquement optimal tel que, pour chaque capteur et chaque actionneur, on identifie les routages valides, on évalue le coût de routage desdits routages valides pour chaque configuration, et l'on choisit le routage valide qui minimise la moyenne, pondérée par les taux de montes de chaque configuration, des coûts de routage pour chaque configuration. Grâce à ces dispositions, on peut comparer les coûts respectifs de deux architectures candidates pour un plan produit en intégrant un mix de gamme et d'options.
Selon des caractéristiques particulières, on synthétise le routage optimal en qualité caractérisé en ce que l'on reprend les étapes ci-dessus, le critère que l'on minimise étant une mesure de qualité préférentiellement exprimée en pannes par million.
Grâce à ces dispositions, on peut comparer les mesures de qualité respectives de deux architectures candidates pour un plan produit.
Selon des caractéristiques particulières, on synthétise le routage optimal en poids caractérisé en ce que l'on reprend les étapes ci-dessus, le critère que l'on minimise étant une mesure de qualité préférentiellement exprimée en pannes par million.
Grâce à ces dispositions, on peut comparer les poids respectifs de deux architectures candidates pour un plan produit.
Selon des caractéristiques particulières, on calcule automatiquement un coût de montage de l'architecture électrique et électronique en fonction d'un coût de montage d'un toron sur une zone, d'un coût de montage d'un connecteur sur une frontière de zone ou sur une zone, d'un coût de montage d'un calculateur sur une zone, d'un coût de montage d'un capteur ou d'un actionneur sur une zone et d'un coût de connexion d'un connecteur entre zones ou dans une zone.
Grâce à ces dispositions, on peut comparer les coûts de montage respectifs de deux architectures.
Selon des caractéristiques particulières, on synthétise le routage optimal pour l'ensemble des configurations, en reprenant les étapes ci-dessus, le critère que l'on minimise étant un coût composé :
- du coût récurrent estimé des pièces, - d'une estimation du coût qualité en anticipation de coût de réparation par zone ce coût étant majoré par un coût constant dépendant de la zone et de sa facilité d'accès,
- d'une estimation du coût du poids en prise en compte de l'usure mécanique et de la consommation liée à une augmentation de poids du véhicule et/ou - d'une estimation du coût de montage.
Grâce à ces dispositions, il est possible de réaliser une architecture optimisant le coût par rapport à un plan produit et non seulement par rapport à une seule variante de produit et prenant en compte tous les aspects de la conception
L'ensemble des opérations du procédé peut être réalisé au moyen d'un ordinateur. Le procédé selon l'invention peut s'appliquer à la synthèse de l'architecture électrique d'un produit nouvellement créé. Le procédé selon l'invention peut également s'appliquer à la synthèse d'une architecture électrique modifiée par rapport à une architecture antérieure.
D'autres avantages, buts et caractéristiques de la présente ressortiront de la description qui va suivre, faite en regard des dessins annexés, dans lesquels :
- la figure 1 représente schématiquement les différentes étapes du procédé selon l'invention,
- la figure 2 est une vue de dessus, en plan des différentes zones d'un véhicule automobile, - la figure 3 est une vue schématique d'éléments de description de zones,
- la figure 4 montre des routages validés dans une zone de portière d'un véhicule,
- la figure 5 montre un exemple du câblage d'une portière de véhicule,
- les figures 6 à 16 représentent des écrans mis en oeuvre pour la conception d'une architecture de système électronique et informatique, - la figure 17 représente des étapes mises en oeuvre pour la spécification d'une variante de prestation, et
- la figure 18 représente des étapes mises en oeuvre dans un procédé de conception d'une architecture de système selon la présente invention.
Avant de détailler des modes de réalisation particuliers de différents aspects de la présente invention, on donne ici des explications sur la terminologie utilisée
- les termes "véhicule" et "produit" sont utilisés indifféremment, la portée de la présente invention ne se limitant pas aux véhicules mais les modes particuliers de réalisation étant détaillés pour un produit constitué d'un véhicule. - les termes "estimation" et "évaluation" sont utilisés indifféremment.
- dans un but de concision, le terme "outil" signifie "outil de conception d'architecture de système".
- lorsque, dans le contexte de la description, la différence entre une unité de contrôle électronique ou un boîtier fusibles et relais n'est pas importante, on parlera simplement de calculateur. Lorsque la gestion de diversité des calculateurs sera discutée, on parlera de type de calculateur pour un calculateur générique d'un réseau de bord, comme par exemple le calculateur d'injection d'un véhicule automobile et de variante de calculateur pour une instance particulière d'un type de calculateur, par exemple tel contrôleur d'injection essence produit par tel équipementier toujours pour un véhicule automobile. Lorsque l'on abordera les réseaux de bord, on parlera de nœud du réseau pour parler d'un type de calculateur, ou d'une variante de calculateur suivant les cas, connecté à un réseau, pour rester cohérent avec la terminologie classiquement employée.
La notion de composant fera généralement référence à un capteur ou un actionneur par opposition à un calculateur. Un composant électronique sera par contre aussi bien un actionneur ou un capteur qu'un calculateur ou un autre composant intelligent aussi appelé en anglais "smart component". Un composant électrique électronique désignera n'importe quel type de composant. En pratique, ces distinctions seront claires à partir du contexte d'utilisation.
Finalement, on parlera simplement de "réponse" pour parler d'une réponse à une demande utilisateur.
La figure 1 représente schématiquement les étapes du processus suivi pour réaliser le routage des fils de l'architecture électrique et électronique ainsi que son évaluation. Certains liens entre certaines des étapes y sont symbolisés par des flèches. Par exemple, la flèche entre les étapes 102 et 104 indique que l'étape 104 est réalisée après l'étape 102. Par contre, il n'y a pas de lien entre l'étape 104 et l'étape 106, ces deux étapes peuvent être réalisées dans un ordre indifférent sans nuire à la qualité du résultat. Pour effectuer le routage des fils et son évaluation, le procédé comporte :
- une étape 102 au cours de laquelle on spécifie la géométrie du véhicule, sous forme de zones, par exemple en mettant en oeuvre un ordinateur qui affiche l'écran illustré en figure 13 et dispose d'un logiciel permettant de réaliser les fonctions décrites en regard de la figure 13 ; Parallèlement à cette étape 102, on fait au moins un des choix ci-après :
- choix d'unités de contrôle électroniques,
- choix de réseaux de communication, - choix de capteurs et actionneurs,
- choix de boîtiers fusibles et relais,
- choix d'une architecture électrique et électronique et on spécifie des caractéristiques des composants électriques et électroniques.
- une étape 104 au cours de laquelle on place des sous-zones dites "d'évitement", dans les zones définies au cours de l'étape 102, comme expliqué en regard des figures 13 et 14 ;
- une étape 106 au cours de laquelle on place des points de routage, des connecteurs, en particuliers entre les zones définies au cours de l'étape 102 ;
- une étape 108 au cours de laquelle on place les composants - une étape 110 au cours de laquelle le logiciel qui implémente le premier aspect de la présente invention effectue automatiquement une synthèse du routage des signaux, un exemple d'un tel routage étant présenté en figure 5 ;
- une étape 112 au cours de laquelle le logiciel effectue automatiquement une synthèse du routage de la puissance, un exemple d'un tel routage étant proposé en figure 5
- une étape 114 au cours de laquelle le logiciel effectue automatiquement une synthèse des liens de masse, un exemple d'un tel routage étant proposé en figure 5 ;
- une étape 116 au cours de laquelle le logiciel effectue automatiquement une évaluation du coût du routage, à partir de fonctions d'estimation des coûts des connecteurs et des fils en fonction de leur dimension et des fonctions d'estimation des coûts des différents composants électroniques et en sommant les coûts des éléments composant l'architecture ;
- une étape 118, au cours de laquelle le logiciel effectue automatiquement une évaluation de la qualité du routage à partir de fonctions d'estimation de la qualité des connecteurs et des fils en fonction de leur dimension et de fonctions d'estimation de la qualité des différents composants électroniques ; et
- une étape 120, au cours de laquelle le logiciel effectue automatiquement une évaluation du poids du routage, à partir de fonctions d'estimation du poids des connecteurs et des fils en fonction de leur dimension et de fonctions d'estimation du poids des différents composants électroniques .
En fonction du résultat de ces évaluations, on modifie les emplacement de point de routage, de connexion et des composants électriques et électroniques, étapes 106 et 108 en vue d'une amélioration et on reprend les étapes de synthèse 110, 112, 114 pour procéder à une nouvelle évaluation et de manière itérative converger vers une solution optimisée.
Lorsque une solution optimisée est déterminée, on procède au calcul d'une spécification technique du câblage constitué du routage synthétisé validé et de connecteurs La figure 2 représente schématiquement le découpage en zones d'un produit, en l'occurrence un véhicule automobile 5 portes avec un hayon. Les différentes zones du véhicule sont représentées suivant une vue de dessus. Ces différentes zones comportent : une zone aile avant droite 202, une zone porte avant droite 204, une zone montant droit 206, une zone porte arrière droite 208, une zone aile arrière droite 210, une zone montant avant droit 211, une zone montant arrière droit 212, une zone hayon 214, une zone pavillon 216, une zone cockpit 218, une zone capot 220, une zone montant avant gauche 222, une zone montant arrière droit 224, une zone face avant 226, une zone aile avant gauche 228, une zone porte avant gauche 230, une zone montant gauche 232, une zone porte arrière droite 234, une zone aile arrière gauche 236, et une zone plancher 240. Ces zones sont, en figure 2, représentées ensemble et orientées suivant une "boussole" 238, placée à titre indicatif, qui permet intuitivement à l'homme du métier de naviguer dans chaque zone en sachant comment elle est située par rapport à celles qui l'entourent, à la fois dans la représentation et dans la réalité. La boussole 238 indique comment les zones sont situées les unes par rapport aux autres, mais ne s'applique pas à chaque zone en particulier. Par exemple, les zones "aile avant droite" 202 et "porte avant droite" 204 sont placées de telle sorte que l'on peut en déduire que la zone "aile avant droite" 202 est à l'avant de la zone "porte avant droite" 204. Pour autant, ces deux zones sont verticales et, localement, ne seront pas représentées selon les orientations indiquées par la "boussole" 238.
De même, on voit en figure 2 que la zone "montant droit" 206 est à droite de la zone "pavillon" 216, mais la zone "pavillon" 216 est horizontale et sera représentée dans une vue locale selon les orientations indiquées par la "boussole" 238 alors que la zone "montant droit" 206 est verticale. La "boussole" 238 sert donc à situer les zones entre elles mais ne s'applique pas nécessairement à la description du contenu de chaque zone.
La figure 3 représente schématiquement des éléments de description de zones et illustre comment sont placés sur une zone "zone horizontale plancher" 318 correspondant en figure 2 à la zone plancher 240, un point de connexion 302, un point de routage 312, un connecteur placé en lieu et place d'un point de routage 304 ou en lieu et place d'un point de connexion 316, une zone d'évitement 314, des composants 306 et 308, qu'il s'agissent de capteurs, actionneurs, unité de contrôle électronique ou boîtiers fusibles et relais.
Un routage de la zone est réalisé, le composant 306 étant routé au point de connexion 302 via le connecteur 304 et le composant 308 étant routé au connecteur 316 via le point de routage 312. D'autre part, la figure 3 illustre les connexions entre zones schématisées par le trait discontinu entre, d'une part, le point de connexion 302 de la zone horizontale plancher 318 et le point de connexion 320 de la zone verticale connexe 324 et, d'autre part, le connecteur 316 de la zone horizontale plancher 318 et le connecteur 322 de la zone verticale connexe 324. La "boussole" 326 indique comment orienter la zone horizontale plancher 318 alors que la "boussole" 328 indique comment orienter la zone verticale connexe 324. On note que ces deux zones sont perpendiculaires, la zone horizontale plancher 318 étant inscrite dans un plan horizontal alors que la zone verticale connexe 328 est inscrite dans un plan vertical. Les points de connexion 302 et 320, lorsqu'ils sont associés, représentent un même point dans l'espace, c'est à dire un point de contact physique entre les zones horizontale plancher 318 et verticale connexe 324. De même, les connecteurs 312 et 316 sont réunis par un mécanisme standard de type "prise mâle/femelle", par exemple le connecteur 312 est un connecteur mâle et le connecteur 316 est un connecteur femelle et ces deux connecteurs sont physiquement liés en un point de contact physique entre les zones horizontale plancher 318 et verticale connexe 324.
La figure 4 représente schématiquement des routages valides dans une zone portière avant gauche 414 correspondant à la zone porte avant gauche 230 illustrée en figure 2. Les sous-zones d'évitement 418, 420 et 422 sont hachurées, et des composants sont représentés, notamment un bouton de commande du lève-vitre 402, une lampe d'éclairage du bouton de commande du lève vitre 404, un moteur de verrouillage 406, un moteur de lève-vitre 408, des connecteurs 410 et 412. La lecture de la zone 414 est simplifiée à l'aide de la "boussole" 416. D'autre part, des points de routage 451 , 452, 457 et 458 ont été placés. On note que certains sommets de la sous-zone d'évitement 422 sont spécifiquement utiles pour les routages, c'est-à-dire fils électriques ou liens, 454, 455 et 456.
La figure 5 représente schématiquement un routage d'un ensemble de fils sur deux zones, d'une part, une zone porte avant gauche 414 et, d'autre part, une zone cockpit 510.
Certains composants sont communs aux figure 4 et 5. D'autres, notamment dans la zone cockpit 510 sont ajoutés : un point à la masse 504, une unité de contrôle électronique 506, un boîtier fusibles et relais 508 et les connecteurs 502 et 512, correspondant respectivement aux connecteurs 410 et 412 de la zone porte avant gauche 414. Le lien entre les connecteurs des deux zones sont symbolisés par les traits en pointillé, en figure 5. En pratique, les connecteurs 502 et 410, par exemple, sont réunis par un mécanisme standard type prise mâle/femelle comme indiqué en regard de la figure 3.
Une représentation en deux dimensions du produit est réalisée comme suit : le produit est découpé en zones dont les dimensions doivent être spécifiées pour coller au mieux à la géométrie du produit considéré. Cette représentation est notamment satisfaisante pour un véhicule automobile dans la mesure ou le câblage peut être en grande partie fixé directement aux tôles et donc à une décomposition du véhicule en zones planes, comme détaillé en figure 2.
Chaque zone représentée est de préférence verticale ou horizontale. Par exemple, on peut associer le plancher d'un véhicule à une zone horizontale et une portière d'un véhicule à une zone verticale. Pour un hayon incliné, on peut choisir l'une ou l'autre des représentations. De plus, on peut indiquer la gauche et la droite, l'avant et l'arrière, le haut et le bas de ladite zone. Ces orientations ont notamment pour objectif que l'homme du métier puisse se retrouver facilement dans le passage d'une zone à une autre, ou d'un vue globale, dans laquelle toutes les zones sont représentées, à une vue locale, dans laquelle une seule zone, par exemple, est représentée. La figure 2 représente une vue de haut des différentes zones de la partie supérieure d'un habitacle d'automobile à cinq portes (y compris le hayon). Le découpage en zones logiques est spécifié, mais les dimensions respectives et les formes des zones ne sont pas représentés sur la figure 2. Les zones sont orientées en figure 2 puisque avant, arrière, gauche et droite de la vue de dessus sont indiqués. Certaines pièces sont horizontales, comme le pavillon, et d'autres verticales, comme les portes.
Chaque zone peut contenir des sous-zones d'évitement, c'est à dire des zones dans lesquelles on ne peut pas faire passer de fils. Par exemple, dans le hayon d'un véhicule, la vitre correspondra à une sous-zone d'évitement.
Pour des raisons de simplicité, les zones peuvent être représentées par des figures géométriques simples comme par exemple des polygones ou encore plus simplement des quadrilatères. Chaque zone a son référentiel et les sous-zones d'évitement d'une zone A sont des formes inscrites dans A, préférentiellement sous forme de polygone ou de quadrilatère.
La figure 3 représente un zoom sur une zone du type de celles décrites dans la figure 2. Il s'agit d'une zone inscrite dans un plan horizontal comme l'indique la boussole
328. Elle se nomme "zone horizontale plancher". Au centre de la pièce, une forme hachurée indique une sous-zone d'évitement 314. Les formes hachurées, dans les figures 4 et 5, indiquent de même les sous-zones d'évitement 418, 420 et 422.
Chaque zone est, par ailleurs, liée aux autres zones par des points de connexion qui servent à spécifier les liens géométriques entre les différentes zones et à spécifier des emplacements où les fils peuvent passer d'une zone à une autre. Un point de connexion entre deux zones est donc représenté sur chacune de ces zones. Un point de connexion peut être un connecteur. Dans ce cas, il est un connecteur sur les deux zones qu'il lie.
Dans la figure 3, le lien entre deux zones, par des points de connexion, est illustré. La zone "zone horizontale plancher" 318 est liée à la zone "zone verticale connexe" 324 par deux connecteurs 302/320 et 316/322. Ces deux connecteurs sont situés à distance égale l'un de l'autre sur chacune desdites zones.
Les points de routage sont des points de regroupement de fil proposés, dans chaque zone, par le concepteur et qui permettent notamment de regrouper les fils en torons.
Préférentiellement, tous les sommets d'une sous-zone d'évitement sont des points de routage afin qu'il existe toujours une solution au problème du routage dans une zone. Sur spécification du concepteur, un point de routage peut être un connecteur.
Dans la figure 3, deux points de routage 304 et 312 sont représentés, dont l'un, 304, est en fait un connecteur.
Un routage entre deux points (par exemple entre un capteur et un actionneur) consiste en une séquence de points de routage ou de connexion. Le fil synthétisé suivant un routage est supposé et représenté rectiligne entre deux points de routage ou de connexion successifs. Un routage est dit valide dans une zone si, d'une part, il ne traverse aucune sous- zone d'évitement et si, d'autre part, étant donnés deux points de routage ou de connexion successifs A et B du routage, alors il n'existe pas de point de routage C atteignable sans traverser une sous-zone d'évitement et tel que les longueurs des segments AC et BC soient inférieures à la longueur du segment AB.
Un routage traversant plusieurs zones par l'intermédiaire de points de connexion entre zone est valide s'il est valide dans chaque zone.
La longueur du routage d'un fil est la somme des distances entre les points de routage ou de connexion successifs qui forment le routage. Le routage est optimal si la longueur du routage est minimale parmi tous les routages valides possibles.
Pour trouver le routage optimal entre deux points, on peut par exemple énumérer tous les routages valides possibles entre ces deux points ne comportant pas de boucle (c'est à dire qui ne passe jamais deux fois par le même point de routage ou de connexion) et choisir le routage le plus court . Dans la figure 4, les points 451 , 452, 453, 454, 455, 456, 457 et 458 sont des points de routage. Les points 410 et 412 représentent des points de connexion entre zones contenant des connecteurs. On note que 454, 455 et 456 sont aussi des sommets d'une sous-zone d'évitement. Les routages possibles pour router le moteur de verrouillage 406 au connecteur 412 sont nombreux : on peut citer le routage (406 - 451 - 452 - 458 - 412) et (406 - 454 - 455 - 456 - 457 - 458 - 412). En fait le routage (406 - 451 - 452 - 458 - 412) ne peut pas convenir car il traverse une sous-zone d'évitement. Finalement, le routage le plus court respectant toutes les clauses est (406 - 454 - 455 - 456 - 458 - 412). En pratique le calcul d'un routage se fait entre deux composants plutôt qu'entre un composant et un point de connexion comportant ou non un connecteur dans une zone. Les composants électroniques et électriques suivant sont placés sur les différentes zones produit. Ces composants sont : les unités de contrôle électroniques : ce sont des composants électroniques capables de commander des signaux de données, c'est à dire de faible puissance, servant notamment à transporter des données logicielles ou interprétables par du logiciel, notamment provenant d'un capteur ou à destination d'un actionneur ; les capteurs et actionneurs ; les boîtiers fusibles et relais: ce sont des composants électroniques capables de commander aussi bien des signaux de faible puissance que des signaux de forte puissance, que l'on qualifie simplement de signal de puissance ; - les sources : sont les sources d'énergie, typiquement une batterie - une source peut être assimilée à un boîtier fusibles et relais particulier ; Les unités de contrôle électroniques assurent préférentiellement le contrôle logique des composants alors que les boîtiers assurent le relais de leur alimentation et les sources assurent l'alimentation de l'ensemble. Comme leur nom l'indique, les boîtiers fusibles et relais contiennent par exemple les fusibles protégeant les différentes charges (composants consommant de l'énergie) placées sur les différents fils liés aux dits boîtiers et contiennent aussi préférentiellement des relais permettant l'activation des charges nécessitant de la puissance.
Préférentiellement, les différents éléments de l'architecture électrique et électronique sont représentés par des points, c'est à dire associés à deux coordonnées dans le référentiel de la zone sur laquelle ils sont placés. Les points de masse sont aussi placés. Les points de masse sont tels qu'un fil dit de masse, connecté à un point de masse, se trouve à un potentiel électrique nul. Les points de masse sont spécifiés par le concepteur. L'architecture électrique et électronique est donnée par : le choix des unités de contrôle électroniques, - le choix des réseaux de communication, le choix des capteurs et actionneurs, le choix des boîtiers fusibles et relais, les liens logiques de ces différents composants entre eux Ces liens sont, notamment, les connexions des unités de contrôle électroniques et des boîtiers fusibles et relais aux différents réseaux de communication. Ces liens peuvent aussi être des liens explicites entre un capteur ou actionneur et une unité de contrôle électronique ou un boîtier fusibles et relais. Notamment, puisque par exemple un capteur peut avoir plusieurs liens électriques avec son environnement, par exemple un lien masse, un lien puissance et un lien pour la transmission d'information, ledit capteur peut être simultanément lié à une masse, un boîtier fusibles et relais et une unité de contrôle électronique.
Le routage de l'ensemble des fils est réalisé par étapes pour un placement donné des différents éléments de l'architecture.
(A) Le routage d'un signal de donnée d'une entrée-sortie d'un composant à une entrée-sortie d'un unité de contrôle électronique est réalisé comme suit :
(a) Si le rattachement du signal de donnée du composant (capteur ou actionneur) est spécifié, c'est à dire que l'on a déjà défini à quelle unité de contrôle électronique le composant est lié pour ledit signal de donnée, alors il s'agit du routage optimal entre le capteur et l'unité de contrôle électronique. (b) Si le rattachement du signal n'est pas spécifié, alors, on rattache préférentiellement le composant à l'unité de contrôle électronique la plus proche, c'est à dire que (i) on calcule le routage optimal Ci pour joindre le composant à l'unité de contrôle électronique Cald en appliquant l'étape précédente (a) et (ii) on sélectionne ensuite le plus court routage et la ou une des unités de contrôle électronique correspondantes, c'est à dire CalCj tel que Cj = min Ci. (B) Le routage d'un signal de puissance d'une entrée-sortie d'un composant à une entrée-sortie d'un boîtier fusibles et relais est réalisé comme suit :
(a) Si le rattachement du signal de puissance du composant (capteur ou actionneur) est spécifié, c'est à dire que l'on a déjà défini à quel boîtier fusibles et relais le composant est lié pour ledit signal de puissance, alors il s'agit du routage optimal entre le capteur et le boîtier fusibles et relais.
(b) Si le rattachement du signal de puissance n'est pas spécifié, alors, on rattache préférentiellement le composant au boîtier fusibles et relais le plus proche, c'est à dire que (i) on calcule le routage optimal Ci pour joindre le composant au boîtier fusibles et relais Cal en appliquant l'étape précédente (a) et (ii) on sélectionne ensuite le plus court routage et le ou un des boîtiers fusibles et relais correspondants, c'est à dire Cal tel que Cj = min Ci.
(C) Pour ce qui est du routage d'un signal de masse d'une entrée-sortie d'un composant, ce composant étant un capteur, un actionneur, une unité de contrôle électronique ou un boîtier fusibles et relais. On rattache préférentiellement le composant au point de masse le plus proche, c'est à dire que (i) on détermine le routage optimal Ci pour atteindre chaque masse Mj et (ii) on sélectionne ensuite le plus court routage ou l'un des plus court M, tel que Cj = min Ci.
(D) Routage d'un réseau entre calculateurs
Les caractéristiques de topologie du réseau doivent être connues : un tel réseau est de préférence organisé en étoile, en ligne ou en boucle suivant les cas.
Pour un réseau CAN par exemple, les topologies en étoile ou en ligne sont possibles. Préférentiellement, le concepteur indiquera sa recommandation. Les raisons de choix d'une topologie sont très variées. Par exemple le réseau en étoile peut être préféré pour des raisons de sûreté de fonctionnement car en cas de coupure du bus, seul un calculateur est isolé alors qu'en cas de topologie en ligne, le réseau est coupé en deux et les conséquences sont a priori plus graves.
Pour une topologie choisie, on cherche ensuite les routages qui minimisent la distance entre les calculateurs.
Pour une topologie en étoile : (a) On choisit un point de contact entre les branches,
(b) On cherche le routage optimal de ce point avec chacune des unités de contrôle électroniques ou chacun des boîtiers fusibles et relais connectés au réseau, (c) On calcule la somme des longueurs desdits routages optimaux,
(d) On applique les trois étapes précédentes pour chacun des points de contacts existants et
(e) On retient le point de contact qui minimise la longueur du réseau. Pour un topologie en ligne :
(a) On choisit un point de routage permettant déconnecter chaque unité de contrôle électronique ou chaque boîtier fusibles et relais au bus. Le bus étant lui-même formé par l'ensemble une séquence des dits points de routage ne coupant pas de sous-zone d'évitement, (b) On détermine l'ensemble desdits points de routage permettant de connecter chaque unité de contrôle électronique ou chaque boîtier fusibles et relais au bus qui minimise la longueur du réseau, par exemple par essais successifs.
(E) Routage d'un signal de puissance d'un calculateur C.
Il se traite comme le routage d'un signal de puissance d'un capteur à un boîtier fusibles et relais.
En figure 5, la zone "zone porte avant gauche" 414 et sa connexion avec la zone "zone extrait cockpit" 512 sont représentés
Le routage complet des différents composants desdites zones est réalisé. Les composants sont tout d'abord liés à l'unité de contrôle électronique UCE 506. Les différents routages générés sont donc, en reprenant les notations utilisées pour décrire la figure 4 :
- moteur de 406 à l'UCE 506 : (406 - 451 - 452 - 410 - 506),
- moteur du lève-vitre 408 à l'UCE 506 : (408 - 458 - 412 - 506),
- bouton de commande du lève-vitre 402 à I' UCE 506 : (402, 452, 410 - 506),
- éclairage du bouton de commande du lève-vitre 404 à l'UCE 506 : (404 - 452 - 410 - 506), et
- de l'UCE 506 à la BFR 508 : (506 - 508).
Les caractéristiques électriques des différents composants peuvent être spécifiées : nombre de pines d'interface, nature des pines (données, masse, puissance), rattachement des pines de données ou de puissance s'ils sont spécifiés, tension minimum de fonctionnement, courant moyen, courant d'appel, puissance consommée, et ceci pour chaque fil de puissance partant du composant.
Le routage évolue conséquemment puisqu'il faut router chaque fil séparément et spécifier une pine pour chaque connecteur impliqué dans le routage d'un nouveau fil.
En figure 5, les moteurs 406 et 408 peuvent avoir, chacun, trois fils de données, puissance et masse, respectivement, et comportent donc des connecteurs à trois pines. Cette fois-ci, les liens à la masse M 504 et au boîtier fusibles et relais BFR 508, qui n'avaient pas été exprimés jusqu'à maintenant, apparaissent sous la forme de nouveaux routages : - moteur de verrouillage 406 / pine 1 à l'UCE 506 / pine 1 (données) : (406 / pine 1 - 451 - 452 - 410 / pine 1 , 506 / pine 1),
- moteur du lève-vitre 408 / pine 1 à l'UCE 506 / pine 2 (données) : (408 / pine 1 - 458 - 412 / pine 1 - 506 / pine 2), - moteur de verrouillage 406 / pine 2 à la BFR 508 / pine 1 (puissance) : (406 / pine
2 - 451 - 452 - 410 / pine 2, 508 / pine 1),
- moteur du lève-vitre L 408 / pine 2 à la BFR 508 / pine 2 (puissance) : (408 / pine 2 - 458 - 412 / pine 2 - 508 / pine 2),
- moteur de verrouillage 406 / pine 3 à masse 504 : (406 - 451 - 452 - 410 / pine 3 - 504), et
- moteur du lève-vitre 408 / pine 3 à masse 504 : (408 - 458 - 412 / pine 3 - 504). Les pines ne sont pas notées pour un lien à la masse car il s'agit préférentiellement d'un vissage ou d'un moyen analogue.
On peut alors calculer la spécification technique du câblage composée des résultats suivants:
- le plan de câblage logique : il s'agit de la description de l'ensemble des segments de fil nécessaires pour réaliser l'architecture électrique-électronique. Chaque fil lie une pine d'un connecteur d'un composant à une pine d'un autre connecteur d'un autre composant et passe, de plus, par un certain nombre de points de routage et de connexion comme spécifié plus haut. C'est la donnée des deux connecteurs et des pines de chaque connecteur aux extrémités, c'est-à-dire au niveau des composants connectés, la séquence des points de routage, ainsi que la séquence des pines des connecteurs, notamment entre zones, traversés, qui définit logiquement le fil. Le plan de câblage logique est la donnée de l'ensemble des définitions logiques des fils qui le constitue. - la spécification des connecteurs : pour chaque connecteur, c'est le nombre de connexions correspondant à des fils de données, le nombre de connexions correspondant à de la puissance et le nombre de connexions correspondant à des fils de masse qui constituent la spécification.
- la spécification des interfaces des unités de contrôle électroniques, des boîtiers fusibles et relais et des capteurs et actionneurs : il s'agit des descriptions des connecteurs de ces composants, sous forme de pines de données, puissance et masse.
Dans la figure 5, le connecteur 410 assure maintenant cinq connexions dont trois de données, une de puissance et une de masse.
L'utilisateur peut aussi souhaiter calculer ou évaluer le coût d'une architecture électrique et électronique, notamment afin de comparer de telles architectures et choisir la moins coûteuse à prestation et qualité égales. Etant donnée une fonction de coût des connecteurs, par exemple basée sur un abaque qui donne une estimation du prix des connecteurs en fonction du nombres de connexions de données, de puissance et de masse, ou basé par exemple sur un prix moyen affecté à chaque connexion d'un fil de données, courant ou masse. Etant donnée une évaluation du coût des composants électroniques, capteurs, actionneurs, unités de contrôle électronique ou boîtiers fusibles et relais.
Etant donnée une fonction de coût des fils basée par exemple sur leur longueur et sur leur type, en prenant par exemple un poids linéaire moyen pour les fils de puissance et de masse, un poids linéaire moyen pour les fils de données, et un coût massique du composant dans lequel sont fabriqués lesdits fils.
On déduit automatiquement de la spécification technique une évaluation de coût pour l'architecture électronique et électronique considérée en sommant les coûts de tous les composants électroniques, de tous les connecteurs et de tous les fils.
Pour estimer le coût de mise en oeuvre d'une opération élémentaire, on peut par exemple procéder comme suit: étant donné un nombre N de lignes assembleur évalué pour chaque opération élémentaire placée sur un calculateur , et une période P d'activation pour chaque opération élémentaire en seconde, étant donné un coût moyen Cl de l'exécution d'une instruction par seconde sur un processeur, étant donné l'espace mémoire MEMO nécessaire pour les données que l'opération élémentaire échange avec les autres opérations élémentaires et les pilotes; étant donnée une estimation du coût CRAM d'un bit en mémoire RAM et une estimation CROM d'un bit en mémoire ROM ou Cflash en mémoire flash. Etant donné le nombre de bits d'un mot, c'est à dire la caractéristique d'être à n-bits (huit, seize ou trente-deux par exemple) du micro contrôleur, le coût d'une opération est: (N/P)*CI + N*n*CROM + MEMO*n*CRAM. Sur certains microprocesseurs 32 bits, certaines instructions occupent 16 bit ce qui permet notamment d'économiser de la mémoire. Cette caractéristique peut être prise en compte en séparant ces deux types d'instructions si l'on peut évaluer un mix pour l'opération élémentaire considérée et en consommant deux fois moins de ROM pour les instructions sur 16 bits. II est à noter que le coût Cl de l'exécution d'une instruction par seconde sur un processeur peut dépendre du type d'application que l'on traite, toutes les instructions ne s'effectuant pas en autant de cycle. Par exemple sur un processeur de vingt MIPS (Million d'Instruction Par Seconde), on peut réaliser vingt millions d'instruction d'un cycle en une seconde, mais seulement un million d'instructions de vingt cycles. Donc suivant le nombre moyen de cycle par instruction nécessaire pour chaque type d'application, on précise cette évaluation. Il est important de noter que le coût moyen d'une instruction, d'un bit de RAM et d'un bit de flash sur un micro contrôleur peuvent par exemple être extrapolés à partir de l'observation d'au moins trois microcontrôleurs (i) dont on connaît le coût (Ci) et les caractéristiques mémoire RAM (R), MIPS (Mj) et Flash (F), et (n,) le nombre de bit d'un mot. En effet pour chaque microcontrôleur, on établit l'équation aux inconnues Cl, CRAM, Cflash: et
CI*Mi+CRAM*ni*Ri+Cflash*ni*Fi = C, Un tel système de trois équation possède une unique solution, les différentes constantes étant non nulles. Lorsque l'on examine de nombreux contrôleurs, cette estimation peut bien sûr être affinée.
Il est à noter que si l'opération élémentaire est l'automate de contrôle d'une prestation, alors l'estimation du nombre de ligne de code est déterminée en fonction du nombre d'état et du nombre de transitions et la période d'activation est déterminée en fonction des exigences de performance sur les différents cas d'utilisation. D'autre part, le coût des différents pilotes matériels peut être évalués en fonction de leur type (tout ou rien, analogique-numérique,..etc) et de leurs caractéristiques électriques.
L'utilisateur peut aussi souhaiter évaluer la qualité d'une architecture électrique et électronique, notamment afin de comparer de telles architectures et choisir celle qui présente le meilleur niveau de qualité, à prestation et coût identiques.
La mesure de la qualité se fait préférentiellement en mesurant le nombre de pannes par million d'unités et par an de l'ensemble de l'architecture, préférentiellement à l'aide d'un logiciel.
Pour calculer ce nombre • le logiciel mesure la qualité de l'ensemble des connecteurs, qu'il s'agisse de connecteurs entre zones ou au sein de zones ou de connecteurs d'entrées/sorties des composants électroniques (capteurs, actionneurs, unités de contrôle électronique, boîtiers fusibles et relais) en affectant par exemple un taux de panne moyen par connexion, par exemple 10 ppm (panne par million d'unités par an) et en multipliant ce taux moyen par le nombre total de connexion dans le système. Pour obtenir une évaluation plus précise, le logiciel prend en compte des moyennes ajustées en fonction du type de connexion : masse, puissance et données, les fils les plus fins étant les plus fragiles. Par exemple on prend 4 ppm par connexion des fils de puissance ou de masse sur une pine et 6 ppm par connexion des fils de données sur une pine, et finalement une estimation de 4 ppm par portion de fil de donnée entre deux connecteurs. Dans ce cas, si l'on reprend la figure 5, et le détail des connexions et fils présenté en description de la figure 5, on peut réaliser l'évaluation suivante pour chaque section: - moteur de verrouillage 406 / pine 1 à l'UCE 506 / pine 1 (données) : (406 / pine 1 - 451 - 452 - 410 / pine 1 , 506 / pine 1): 3*6ppm + 2* 4 ppm soient 26ppm
- moteur du lève-vitre 408 / pine 1 à l'UCE 506 / pine 2 (données) : (408 / pine 1 - 458 - 412 / pine 1 - 506 / pine 2): 3*6ppm + 2* 4 ppm soient 26ppm - moteur de verrouillage 406 / pine 2 à la BFR 508 / pine 1 (puissance) : (406 / pine
2 - 451 - 452 - 410 / pine 2, 508 / pine 1): 3*4ppm soient 12 ppm
- moteur du lève-vitre L 408 / pine 2 à la BFR 508 / pine 2 (puissance) : (408 / pine 2 - 458 - 412 / pine 2 - 508 / pine 2), 3*4ppm soient 12 ppm
- moteur de verrouillage 406 / pine 3 à masse 504 : (406 - 451 - 452 - 410 / pine 3 - 504), soient 3*4 ppm
- moteur du lève-vitre 408 / pine 3 à masse 504 : (408 - 458 - 412 / pine 3 - 504). soient 3*4 ppm pour un total de 100ppm
Si, maintenant on prend en compte une épissure en 452, alors, les ppm correspondant à la duplication de fils en aval de l'épissure, vu des actionneurs 406 et 408, sont à supprimer soit 3*4 ppm. En tenant compte d'une épissure de puissance on trouve 88ppm comme qualité du routage optimisé. La prise en compte d'une épissure de masse au même point de routage permet d'économiser encore 12ppm pour aboutir à 76ppm. L'optimisation sur une évaluation de coût consisterait de manière similaire à supprimer le coût des portions de fils et des pines de connecteur supprimées grâce à l'épissure.
• l'outil mesure la qualité des composants électroniques qui est spécifiée dans une base de donnée des composants et peut être décrite en fonction du type de composant ou spécifiquement pour chaque composant, par exemple on peut attacher une évaluation à 100 ppm à toutes les unités de contrôle électroniques. » L'outil additionne ensuite les mesures de l'ensemble des composants constituant l'architecture électrique et électronique.
L'utilisateur peut aussi raffiner la stratégie de routage en intégrant des épissures pour les fils de puissance et les fils de masse. On peut pratiquer ces épissures au niveau des connecteurs ou au sein d'une zone, préférentiellement au niveau d'un point de routage. Réaliser une épissure de masse consiste à joindre tous les (n) fils de masse passant en un point, et notamment en un point de connexion ou un point de routage. De la sorte, en remontant vers la masse la plus proche, on économise d'une part des fils et d'autre part des pines de connexion correspondant aux (n-1) fils enlevés.
Réaliser une épissure de puissance consiste à joindre des fils de puissance qui, d'une part, passent en un point commun, notamment en un point de connexion ou en un point de routage, et, d'autre part, joignent des charges à un boîtier fusibles et relais commun. Par exemple en Figure 5, le fil d'alimentation du moteur de verrouillage 406 et le fil d'alimentation de la lampe 404 peuvent être joints au niveau du point de routage 452 ou encore au niveau du connecteur 410. De telles épissures servent à économiser des pines au niveau des connecteurs et les morceaux de fil ainsi supprimés. On cherche donc à minimiser la longueur des fils et on choisira de pratiquer l'épissure au point de routage 452 afin d'économiser les longueurs de fil entre 452 et 410. Le point 452 est celui qui minimise les longueurs de fil pour la réalisation de l'épissure dans l'exemple de la figure 5.
Pratiquer une épissure au niveau d'un connecteur revient à lier entre elles les pines du connecteur correspondant aux fils que l'on souhaite joindre.
On peut alors améliorer la synthèse du routage en cherchant si une ou plusieurs épissures des fils de masse ou des fils de puissance permettrait de minimiser le coût global de l'architecture. Il faut pour cela entrer de nouvelles données dans la base de coût des composants unitaires notamment le coût d'une épissure en fonction du nombre de fils joints et le coût d'un épissure au niveau d'un connecteur en fonction du nombre de fils joints.
Les figures 6 et suivantes décrivent un outil de conception d'architecture de système et un procédé de conception d'une spécification d'un système matériel et logiciel mettant en oeuvre cet outil.
Cet outil est particulièrement adapté aux cas de systèmes complexes comportant un ensemble de calculateurs réalisant de nombreuses prestations ou services au bénéfice d'un utilisateur, chaque prestation présentent de nombreux cas d'utilisation. Par exemple, les systèmes électroniques et informatiques de véhicules sont particulièrement visés par cet outil.
Des prestations sont définies par ce que l'utilisateur veut (par exemple la mise en route de la climatisation, d'essuie-glaces) ou par ce qu'on lui propose (par exemple une sécurité passive, notamment en cas d'accidents). Elles sont aussi définies par des capteurs et/ou des actionneurs qu'elles mettent en oeuvre. Elles correspondent, chacune, à une réalisation matérielle capteur/logiciel/actionneur. Le constructeur dispose d'une marge de manoeuvre dans la définition de l'architecture interne du système électronique/informatique, notamment dans le choix des réseaux de bord et des boîtiers électroniques connectés sur ces réseaux et l'outil de conception présenté ici permet la conception de cette architecture. A partir des prestations, l'outil de conception permet de déterminer des spécifications plutôt que des produits finis. Néanmoins, cet outil détermine aussi des interfaces et ce que doivent comporter les éléments et leur communication avec le système électronique/informatique.
En particulier, cet outil ne vise pas à programmer les calculateurs de manière automatique mais à gérer des compromis coût/qualité/délais du système spécifié. L'outil de conception est implémenté sous forme d'un logiciel fonctionnant sur un ordinateur personnel et utilisant une base de données et des ressources (operating System et distribution sur le réseau) connues.
Conformément à un aspect de la présente invention : - chaque prestation représente un service rendu à un utilisateur,
- on définit un ensemble de cas d'utilisation formalisés de chaque prestation, chaque cas d'utilisation formalisé comportant un contexte d'origine, une demande de l'utilisateur, éventuellement implicite, et une réponse du système correspondant à un changement de son état, et - le système est organisé et spécifié pour effectuer la réponse, sur détection de émission de la demande dans le contexte d'origine.
Dans ce but, selon un aspect de la présente invention, le procédé comporte une étape de conception, pour chaque prestation, d'un automate de contrôle de la prestation destiné à être mis en oeuvre par le système de composants matériels et logiciels et qui représente le comportement de ce système. Cette étape de conception comporte, pour chaque prestation une étape de définition d'un cas d'utilisation formalisé de la prestation, spécifié par un contexte, une demande d'un utilisateur au système et une réponse du système correspondant à un changement de son état et, de manière itérative, jusqu'à ce que tous les cas d'utilisation de la prestation aient été traités : - une étape d'ajout d'un cas d'utilisation formalisé de la prestation, spécifié par un contexte ou situation initiale du système, une demande d'un utilisateur au système et une réponse du système correspondant à un changement de son état,
- et, de manière itérative, pour chaque état déjà construit, on cherche s'il est compatible avec le contexte du cas d'utilisation formalisé ajouté et, si oui, on construit un nouvel état du système relié audit état déjà construit par la demande du cas d'utilisation formalisé ajouté, le nouvel état tenant compte de l'état déjà construit et de sa modification par la réponse du cas d'utilisation formalisé ajouté.
De cette manière, on synthétise, pour la prestation, l'automate de contrôle de la prestation constitué de l'ensemble des couples d'état reliés par les demandes formant les transitions dudit automate.
Le contexte représente au moins un mode (ou paramètre) de fonctionnement du système, les modes étant transversaux aux prestations et hors du contrôle direct des prestations, par exemple un mode représentant un niveau d'énergie disponible (batterie faible, sur batterie, en cours de démarrage, moteur tournant, par exemple), un autre mode représentant un type d'utilisateur du système (concepteur, fabricant, propriétaire du véhicule, conducteur ou passager du véhicule, service après-vente, garage automobile, par exemple) et un autre mode représentant un état accidenté ou non d'un véhicule. II faut noter que, bien que la mise en route du moteur soit une des prestations du véhicule, le changement de niveau d'énergie disponible (lié à l'entraînement de l'alternateur par le moteur) n'est pas directement sous le contrôle de cette prestation.
Dans le mode de réalisation décrit ici, tout contexte s'inscrit dans une phase de vie du système constitué d'un ensemble de combinaison des modes de fonctionnement du véhicule, la déclinaison en mode des phases étant ainsi transversale aux prestations. In fine, un contexte correspondra à un ensemble de couples (phase, état du système), chaque état étant en fait caractérisé par la réponse système lorsqu'on y accède.
Par exemple, le cas d'utilisation « dans le contexte ou le véhicule est condamné, l'utilisateur appuie sur son badge de décondamnation et le véhicule se décondamne » s'applique aux états « véhicule verrouillé » dans les phases "moteur tournant" et "moteur arrêté", si ces deux phases ont été identifiées comme pertinentes par d'autres cas d'utilisation formalisés de la prestation "déverrouillage". Chaque phase correspond à un ensemble de combinaisons de modes dans lesquels le comportement de la prestation est uniforme, c'est à dire qu'on y observe les mêmes états et les mêmes demandes client, ou, formulé autrement, les mêmes demandes clients et les mêmes réponses système à partir d'un état donné.
Le tableau ci-dessous définit un ensemble de phases pour une véhicule donné.
ENERGIE UTILISATEUR ETAT VEHICULE PHASE batterie faible concepteur véhicule non accidenté phase 1 batterie faible concepteur véhicule accidenté phase 2 batterie faible fabricant véhicule non accidenté phase 1 batterie faible fabricant véhicule accidenté phase 2 batterie faible propriétaire véhicule non accidenté phase 3 batterie faible propriétaire véhicule accidenté phase 2 batterie faible conducteur véhicule non accidenté phase 1 batterie faible conducteur véhicule accidenté phase 2 batterie faible SAV véhicule non accidenté phase 4 batterie faible SAV véhicule accidenté phase 5 batterie faible garage véhicule non accidenté phase 4 batterie faible garage véhicule accidenté phase 5 batterie normale concepteur véhicule non accidenté phase 6 batterie normale concepteur véhicule accidenté phase 2 batterie normale fabricant véhicule non accidenté phase 6 batterie normale fabricant véhicule accidenté phase 2 batterie normale propriétaire véhicule non accidenté phase 7 batterie normale propriétaire véhicule accidenté phase 2 batterie normale conducteur véhicule non accidenté phase 6 batterie normale conducteur véhicule accidenté phase 2 batterie normale SAV véhicule non accidenté phase 4 batterie normale SAV véhicule accidenté phase 5 batterie normale garage véhicule non accidenté phase 4 batterie normale garage véhicule accidenté phase 5 démarrage concepteur véhicule non accidenté phase 8 démarrage concepteur véhicule accidenté phase 9
Dans ce tableau, tous les triplets de modes de fonctionnement sont mis en correspondance avec des phases, chaque phase représentant un ensemble de combinaisons des valeurs possibles des modes de fonctionnement. Si le comportement du véhicule est toujours le même, une seule phase est définie dans le tableau, sinon, il y a différenciation de plusieurs phases.
L'ensemble des cas d'utilisation formalisés représentent toutes les réponses ou absences de réponse du système dans toutes les phases du système.
L'outil permet une étape de complétion au cours de laquelle, pour chaque réponse, c'est-à-dire un état du système, on envisage toutes les demandes clients non encore traitées et on demande au concepteur si un traitement de la demande doit être effectué dans l'état correspondant à cette réponse. Seules les demandes clients peuvent avoir une action sur la prestation.
L'outil de conception permet aussi une étape de correction au cours de laquelle si, dans un même état de départ, deux états de l'automate de contrôle de la prestation sont reliés par des demandes différentes, alors on détermine la nécessité de définir une priorité entre les réponses du système et on incorpore cette priorité comme un attribut des sorties de l'état. Une information de priorité vient typiquement après la conception des cas d'utilisation formalisés. Il est possible que pour des raisons mécaniques ou autres, deux demandes potentiellement concurrentes ne soient en fait jamais réalisables simultanément. Dans ce cas il faut attendre une étape de conception plus avancée pour être sûr qu'il n'est pas nécessaire de spécifier une priorité, à moins que cela puisse être garanti directement (par exemple : ouvrir une porte et fermer la même porte ne peuvent être réalisés simultanément). De plus, si deux demandes identiques mènent à des états différents, il y a alors une incohérence à corriger et l'une des demandes doit être supprimée et le cas d'utilisation correspondant doit être précisé en conséquence.
On observe qu'un changement de contexte est pris en compte par le système de la manière suivante : - chaque changement de contexte est un changement d'état objet d'un CUF ;
- on définit les réponses aux changements de contexte comme des cas d'utilisation formalisés ;
- on définit les changements de contexte comme des demandes de cas d'utilisation formalisés.
Si une prestation en influence une autre (par exemple un même afficheur est partagé par deux prestations, par exemple autoradio et système de navigation), on ajoute une prestation pour la partie en intersection, de manière à résoudre les conflits entre les prestations. Cette prestation aura pour objectif d'arbitrer lorsque deux actions concurrentes seront appliquées sur un composant donné par deux prestations, laquelle des prestations est prioritaire ou si une action spécifique correspondant à ce cas particulier doit être effectuée. Une telle prestation n'est typiquement pas spécifiée à partir de cas d'utilisation mais plutôt par identification des états des deux prestations dans lesquels des réactions menant à conflit (par rapport à un ou plusieurs composants données) sont identifiées. L'automate de contrôle de la prestation est réalisé par programmation d'au moins un calculateur de commande de la prestation correspondante.
L'outil comporte différentes pages accessibles en cliquant sur des onglets. Ces pages sont décrites en regard des figures 6 à 16. Par souci de clarté, dans les figures 6 à 16, les titres des onglets et des éléments de listes sélectionnés par le concepteur sont soulignés et en caractères gras.
Comme illustré en figure 6, l'interface utilisateur 600 de cet outil logiciel comporte :
- des menus déroulant 601 à 608,
- six onglets horizontaux 611 à 616,
- une zone de liste hiérarchisée 620 et - une zone graphique 630.
Les menus déroulants 601 à 608 sont représentés par leurs titres "File", "Edit", "View", "Dictionaries", "Windows", "Tools", "Import/export" et "Help". En cliquant sur l'un de ces titres, avec le bouton gauche de la souris, on fait apparaître un menu déroulant comportant des options participant à la mise en oeuvre du procédé (ouverture, édition, enregistrement, fermeture de fichier, couper, copier, coller des éléments sélectionnés, modes de visualisation, lexique, outils, importation ou exportation de fichiers, aide ...). Lorsqu'il travaille à la conception d'une architecture de système électronique et informatique d'un véhicule, le concepteur n'a pas nécessairement à utiliser ces menus déroulants 601 à 608. Quel que soit l'onglet sélectionné, parmi les onglets 611 à 616, l'outil de conception présente un écran comportant une partie liste hiérarchisée (à gauche sur les figures 6 à 16) représentant une description hiérarchisée et une partie graphique (à droite sur les figures 6 à 16) donnant, en fonction d'une sélection, par l'intermédiaire d'un dispositif de pointage (dans la suite de la description, une souris), d'un élément de la liste hiérarchisée, une vue synthétique concernant l'élément sélectionné.
Il est important de noter ici que, pour au moins une interface utilisateur de l'outil de conception, c'est-à-dire pour au moins un onglet, un niveau hiérarchique de la liste hiérarchisée représente des prestations. Dans le mode de réalisation illustré aux figures, les trois premiers onglets 611 à 613 présentent cette caractéristique.
Avec une souris (non représentée), l'utilisateur peut fait apparaître des menus surgissant (en anglais "pop-up menu") en cliquant sur l'un des boutons droit ou gauche de la souris, dans l'une des zones de liste ou de graphique.
Pour concevoir l'architecture et les spécifications du système, l'utilisateur sélectionne successivement des onglets horizontaux 611 à 616 en cliquant dessus, sachant que l'une des qualités de l'outil de conception est que l'utilisateur peut sélectionner les onglets dans l'ordre qu'il souhaite. Les onglets horizontaux ont les titres suivants :
- "Requirements", onglet 611 ,
- "Feature description", onglet 612,
- "Feature architecture", onglet 613,
- "Operational Architecture", onglet 614, - "Hardware architecture", onglet 615,
- "Frame description", onglet 616.
Ces onglets représentent, dans cet ordre, plusieurs étapes du procédé objet de la présente invention :
Ces titres apparaissent intégralement lorsque les onglets correspondants sont sélectionnés et sous forme abrégée ("REQ" 611 , "FUNC" 612, "MAP" 613, "OPER" 614, "HWD" 615 et "MSG" 616, respectivement) le reste du temps.
Pour concevoir l'architecture d'un système, le concepteur sélectionne d'abord l'onglet 611 "Requirements" et observe l'écran illustré en figure 6. On observe, à gauche, la zone de liste hiérarchisée 620 qui comporte une partie d'une liste dont les cinq niveaux de hiérarchie les plus élevés sont : nom du véhicule services ou prestations variantes de prestation cas d'utilisation lien entre états
Comme il est connu dans le domaine de la recherche de fichier dans un environnement d'ordinateur individuel, de type PC par exemple, les éléments de niveau hiérarchique inférieur peuvent être apparents ou non. Par exemple, lorsque la liste ne contient, de manière apparente, que des noms de véhicule, en cliquant avec le bouton gauche de la souris sur un nom de véhicule, on voit apparaître la liste des services ou prestations proposées sur ce véhicule. En sélectionnant un service, on rend apparente la liste des variantes de prestation qui la concerne et ainsi de suite.
En cliquant avec le bouton droit de la souris sur un élément affiché, on peut éditer la liste de niveau hiérarchique juste inférieur, c'est-à-dire ajouter, modifier ou supprimer un cas d'utilisation en cliquant sur une variante d'utilisation, par exemple. Cette édition se fait par l'intermédiaire d'un menu surgissant au moment où on clique qui comporte, par exemple, les options "ajouter", "retirer", "propriétés" et "montrer les différences" (option qui permet de comparer deux éléments de même niveau hiérarchique, y compris sur deux véhicules différents).
Un cas d'utilisation ("use case") est, dans l'outil de conception, défini par une phase initiale (par exemple un niveau d'énergie disponible) transversale par rapport au véhicule, un état initial (par exemple la position d'actionneurs), une demande ou requête, une phase finale et un état final.
Par exemple, dans la prestation "accès" qui concerne les ouvrants du véhicule, on ajoute un nouveau cas d'utilisation (CU) concernant ce qui doit être fait à la suite d'un accident grave. Pour ce nouveau cas d'utilisation, on définit un nom "après un crash" et une description textuelle "quel que soit le contexte initial du véhicule, le contact étant mis, si un crash est détecté, alors tous les accès doivent être décondamnés". Le nom et la description sont appelées "propriétés" du nouveau cas d'utilisation.
En figure 6, on représente l'interface, lorsque le cas d'utilisation "Utilisateur ouvre coffre" est sélectionné. Lorsque l'on sélectionne un élément de la liste hiérarchisée, par un clic gauche de la souris, on observe, dans la partie graphique 630, une représentation synthétique de cet élément.
Selon le niveau de l'élément de la liste hiérarchique sélectionné, on observe, dans la zone graphique 630 : - nom du véhicule : la liste des prestations
- services ou prestations : la liste des variantes de prestation
- variantes de prestation : la liste des cas d'utilisation
- cas d'utilisation : les différentes réalisations du cas d'utilisation par un ensemble de transitions d'état dans les différentes phases de la prestation.
C'est d'ailleurs la sélection qui est présentée dans la partie graphique 630 - lien entre états : des exigences de performance par rapport aux différentes opérations élémentaires qui sont réalisées dans l'état d'arrivée (cf l'exemple décrit plus haut). Par exemple, par un clic gauche, sur une variante d'une prestation, on fait afficher, dans la partie graphique, une liste des cas d'utilisation, avec leur description, dans un texte, chaque paragraphe correspondant à un cas d'utilisation. Par un clic gauche sur un cas d'utilisation formalisé, on fait apparaître, dans une succession verticale et sous des en-têtes
650 et 651 indiquant les phases concernées, "phase 1 " et "phase 2", des états initiaux 660 à 663 et terminaux 664 à 667 représentés par des rectangles et reliés par des liens 668 à 671.
On voit apparaître sur ces liens le nom de la demande client qui provoque le passage de l'état initial à l'état final.
On observe que pour rendre "formalisé" un cas d'utilisation, on sélectionne le cas d'utilisation avec un clic droit et, dans le menu surgissant, on choisit "définition de lien" pour mettre en place des liens, chaque lien étant défini dans une phase et entre deux états du véhicule (par exemple "portes fermées, coffre fermé" et "portes fermées, coffre fermé, une porte ouverte"). A cet effet, un menu contextuel comporte quatre zones, "phase initiale", "état initial", "phase finale" et "état final" qui permettent de sélectionner entre toutes les phases déjà définies ou entre tous les états déjà définis, ceux qui représentent le cas d'utilisation. Avec ce menu contextuel, et grâce à des boutons, on peut ajouter des états et des phases dans les listes d'états et de phases proposées. Lorsque l'on travaille à définir un cas d'utilisation, on ajoute des phases qui sont propres à la prestation concernée alors que les modes sont pour toutes prestations.
Par exemple, la prestation "frein" comporte quatre phases : - freinage d'urgence ("emergency brake"),
- freinage ("brake"),
- panne de freinage ("failure brake") et
- fonctionnement normal des freins ("brake nominal phase").
Par exemple, pour la prestation "climatisation", deux phases sont définies, l'une pour les faibles niveaux d'énergie disponible, pour lesquels la ventilation est effectuée sans refroidissement de l'air ventilé, trop consommatrice d'énergie, et l'autre pour le cas du moteur tournant, la climatisation étant effectuée avec refroidissement de l'air ventilé.
L'algorithme de fonctionnement d'une prestation est représenté par des blocs rectangulaires, représentants des états, et des flèches, représentant une action ou inaction provoquant une transition entre états. Par convention, les flèches partant d'un état quittent le bloc représentant cet état sur l'une de ses faces verticales droite ou gauche alors que les flèches atteignent les états sur l'une des faces horizontales haute ou basse du bloc correspondant.
Une transition représente une demande du client. Par exemple un clic sur un badge d'ouverture de coffre fait passer de l'état "tout fermé" dans lequel tous les ouvrants du véhicule sont fermés, à un état "portes fermées / coffre ouvert". Pour chaque état, on définit ainsi un ensemble d'opérations élémentaires qui doivent fonctionner ou être exécutées dans ledit état. L'ensemble des états et des transitions forme un automate de contrôle associé à la prestation.
On observe que les états peuvent être considérés comme des "ressentis clients", les transitions étant les demandes du client, éventuellement implicites. On comprends que les phases sont des attributs des états mais que deux états identiques à l'exception de leur phases (phases "avant contact" et "après contact", par exemple) sont considérés comme deux états indépendants.
On observe aussi que le véhicule ne peut pas être dans deux états simultanément pour la même prestation et qui si deux prestations ne sont pas indépendantes (par exemple autoradio et système de guidage utilisant le même afficheur), on ajoute une prestation d'arbitrage appelée sur requête d'au moins une des prestations en question qui détermine comment va se comporter le système lorsque les deux prestations utiliserons les mêmes ressources. Par exemple pour décrire une définition de lien dont la logique est :
- "quel que soit le contexte initial du véhicule, le contact étant mis, si un crash est détecté, alors tous les accès doivent être décondamnés", alors si les portes sont déjà décondamnées, il n'est pas nécessaires de les décondamner ; on sélectionne la phase "Icontact mis" et l'état initial ("start state") "véhicule condamné par le bouton habitacle" et on sélectionne le lien vers l'état final "décondamnation d'urgence" passant par la transition ou demande "un crash est détecté". On le répète pour tous les états initiaux sauf "tous ouvrants ouverts" et seulement pour la phase "contact mis".
Dès qu'un lien a été ajouté et validé, un graphique apparaît dans la partie droite : deux rectangles surmontés du nom de leurs phases respective ("contact mis" et "crash") et un lien arrondi, avec, sous le lien, le nom de la transition. Le cas d'utilisation devient alors un cas d'utilisation formalisé ("CUF").
Lorsque l'on ajoute un état en regard d'un nouveau cas d'utilisation, on doit regarder s'il est utile dans les autres cas d'utilisation.
Par exemple si on ajoute le cas d'utilisation "condamnation enfant" qui permet d'empêcher que des enfants puissent ouvrir des portes arrières, il faut ajouter l'état correspondant dans la description du cas d'utilisation "crash". En traitant tous les cas d'utilisation de toutes les variantes d'une prestation donnée, on a créé un automate de contrôle de la prestation qui apparaît, dans la zone graphique 630 lorsque l'on sélectionne la prestation après avoir cliqué sur l'onglet « FUNC ».
Lorsque l'onglet "Requirements" est sélectionné, comme illustré en figure 6, aucun onglet vertical n'apparaît latéralement sur la zone graphique 630.
Le concepteur sélectionne ensuite l'onglet "FUNC" ou "feature description". La figure 7 illustre une image de l'interface utilisateur qui est alors affichée sur l'écran du poste de conception.
En figure 7, l'interface utilisateur 700 de cet outil logiciel comporte alors : - les menus déroulant 601 à 608,
- les six onglets horizontaux 611 à 616,
- une zone de liste hiérarchisée 720,
- une zone graphique 730, et
- des onglets verticaux 731 et 732. Les onglets verticaux 731 et 732 sont nommés respectivement "functional diagram" et "feature" et sont accolés à la zone graphique 730. Ils servent à sélectionner un contenu à afficher dans cette zone graphique 730, comme exposé plus loin.
A gauche, la zone de liste hiérarchisée 720 comporte une partie de la liste dont les dix niveaux de hiérarchie les plus élevés sont : nom du véhicule services ou prestations variantes de prestation phase état groupe d'opérations élémentaires opération élémentaire donnée pilote (« driver ») composant. Les trois niveaux de hiérarchie les plus élevés sont identiques à ceux de la liste
620 et comportent, en particulier, les services ou prestations. La sélection de l'un des composants de la liste hiérarchisée, par un clic gauche provoque avec l'onglet "feature" 732 sélectionné, l'apparition, dans la partie graphique 730, de l'ensemble des éléments de la liste de niveau immédiatement inférieur avec tantôt un flot de contrôle entre les composants si l'on pointe et clique avec la souris sur variante de prestation (les phases apparaissent en partie gauche liées entre elles par des demandes clients correspondant à des transitions de phase) ou sur une phase (les états de la phase apparaissent en partie gauche, liés entre eux par les « demandes clients").
Lorsque l'on clique avec le bouton droit sur un item, dans la liste hiérarchisée 720, l'outil permet notamment de rajouter ou d'enlever des éléments dans le niveau hiérarchique immédiatement en dessous. En cliquant sur l'un des items phase, état ou groupe d'opérations élémentaires, il est de plus possible de rajouter une opération élémentaire transversalement dans respectivement ladite phase, c'est à dire dans l'ensemble des états de ladite phase et en indiquant dans quel groupe d'opérations élémentaires on rajoute ladite opération élémentaire, dans ledit état notamment en indiquant dans quel groupe d'opérations élémentaire on rajoute l'opération élémentaire dans ledit état, et dans ledit groupe d'opérations élémentaires. Par un clic droit sur l'item phase de la liste hiérarchisée 720, il est possible de rajouter une transition de phase, l'outil demande alors la phase d'arrivée, la demande client correspondant à la transition, et les états de départs et d'arrivée pour la transition de phase. Par un clic droit sur l'item état de la liste hiérarchisée 720, il est possible de rajouter une transition d'état, l'outil demande alors quel est l'état d'arrivée de la transition et quelle est la demande client correspondante.
Plus généralement, en cliquant sur un niveau de la liste hiérarchisée 720, il est possible d'ajouter ou d'enlever un élément du niveau immédiatement inférieur.
Toujours dans le contexte où les onglets « FUNC » 612 et « Feature » 732 ont été sélectionnés, si l'on pointe et clique sur un état, on obtient alors en partie droite, dans la zone graphique 730, les groupes d'opération élémentaires, représentés comme les nœuds d'un graphe orienté, chaque flèche représentant le flot de données entre le groupe d'opérations élémentaires de départ et le groupe d'opérations élémentaires d'arrivée. Ce flot de données est défini par rapport au flot de données entre opérations élémentaires, dans la mesure ou toute donnée apparaissant est en fait produite par une ou plusieurs opérations élémentaires du groupe d'opérations élémentaires de départ et consommé par une ou plusieurs opérations élémentaires du groupe d'opérations élémentaires d'arrivée.
Toujours dans le contexte où les onglets « FUNC » 612 et « Feature » 732 ont été sélectionnés, si l'on pointe et clique sur une opération élémentaire, on observe dans la zone graphique 730, l'ensemble des autres opérations élémentaires et composants (capteurs, actionneurs) avec lesquels l'opération élémentaire échange des informations. Encore une fois, il s'agit d'un graphe orienté et, sur chaque lien, on peut trouver l'ensemble des données échangés entre l'opération élémentaire sur laquelle on a pointé et l'opération élémentaire ou le composant qui reçoit ou émet à l'autre bout suivant le sens de la flèche du graphe orienté. L'opération élémentaire sélectionnée est caractérisée par une couleur spécifique ou un emplacement spécifique (centre de l'écran, couleur rouge) afin d'être aisément distinguée des autres opérations élémentaires et des capteurs et actionneurs. De même, les opérations élémentaires autres que celle sur laquelle on a cliqué dans la liste hiérarchisée 720, sont distinguées des composants en prenant une couleur différente.
Toujours dans le contexte où les onglets « FUNC » 612 et « Feature » 732 ont été sélectionnés, si l'on pointe et clique maintenant sur le niveau donnée, c'est à dire le huitième niveau de la hiérarchie présentée plus haut, on voit apparaître en partie droite de l'écran, dans la zone graphique 730, un graphe avec au centre du graphe la donnée sélectionnée et, entourant cette donnée, les opérations élémentaires qui produisent (sur la gauche) ou qui consomment (sur la droite) cette donnée et éventuellement le ou les capteurs qui produisent ou le ou les actionneurs qui consomment cette donnée. De préférence, on met les consommateurs à droite et les producteurs à gauche. Il est naturel qu'il y ait plusieurs consommateurs pour une donnée. Il peut être normal que la même donnée soit produite par plusieurs opérations élémentaires, par exemple si celles-ci ne fonctionnent pas dans les mêmes phases.
Selon le niveau de l'élément de la liste hiérarchisée sélectionné, on observe, dans la zone graphique 730, lorsque l'onglet "feature" 732 est sélectionné : nom du véhicule le graphe orienté dont les nœuds sont des variantes de prestation enveloppe et les flèches les flots de données entre ces variantes de prestation. Ce graphe est conditionné par le choix d'une configuration c'est à dire le choix d'une variante de prestation par prestation. Ceci est représenté en figure 15. services ou prestations la liste des variantes de la prestation et pour chacune, la vue enveloppe type schéma 830. variantes de prestation : vue enveloppe de type schéma illustrée en figure
8. phase : vue enveloppe de type schéma illustrée en figure 8 pour les opérations élémentaires de la phase et en restreignant les autres prestations aux combinaisons de mode de la phase état vue enveloppe de type schéma illustré en figure 8 pour les opérations élémentaires de l'état et en restreignant les autres prestations aux combinaisons de mode de la phase dans laquelle l'état est spécifié. - groupe d'opérations élémentaires : comme lorsque l'onglet "functional diagram" est sélectionné
- opération élémentaire : un graphe avec au centre l'opération élémentaire sélectionnée et autour d'elle les capteurs, actionneurs et autres opérations élémentaires de l'architecture dans son ensemble auxquels elle est liée les arrêtes du graphe sont les flots de données entre les nœuds.
- donnée : les opérations élémentaires, capteurs ou actionneurs auxquels la donnée est liée directement sont affichés dans un graphe. Les capteurs ou opérations élémentaires qui produisent la donnée apparaissent à sa droite alors que les actionneurs ou opérations élémentaires consommant la donnée sont placés à gauche de la donnée. Les flèches indiquent le sens de passage de la donnée (du producteur vers le consommateur). - pilote : les caractéristiques du pilote, type d'entrée/sortie analogique-numérique, tout-ou-rien, ses caractéristiques électriques.
- - capteur/:actionneur : un graphe avec au centre le capteur ou l'actionneur sélectionné et autour de lui les opérations élémentaires de l'architecture dans son ensemble auxquels il est lié, les arrêtes du graphe sont les flots de données entre les nœuds.
En sélectionnant une prestation au deuxième niveau hiérarchique, lorsque l'onglet
"functional diagram" 731 est sélectionné, on observe, dans la partie graphique 730, l'automate correspondant, avec des états (ou situations opérationnelles) et les seules transitions de phase. En figure 7, on voit un automate correspondant à la variante "badge" de la prestation "service ouvrants" : états 761 à 766 et transitions 768, 769 et 772. Si on clique avec le bouton gauche sur une flèche représentant une transition, on voit apparaître un menu contextuel qui décrit toutes les demandes qui provoquent cette transition. Généralement une seule demande provoque cette transition, par exemple la demande "contact_on" qui correspond à la mise du contact, par exemple avec la clé de contact, fait passer de la phase "contact non mis" à la phase "contact mis", mais plusieurs demandes relevant de cas d'utilisation formalisés peuvent lier deux états. Par exemple dans une version très simplifiée de la prestation déverrouillage, il est possible que les états véhicule verrouillé et véhicule déverrouillé soient liés par les demandes clients « demande de condamnation par badge » et « demande de condamnation par le bouton de commande des ouvrants dans le véhicule ». Pourtant, on aura pu formuler deux cas d'utilisations formalisés différents, l'un pour la décondamnation à distance et l'autre pour la décondamnation dans le véhicule.
Le quatrième niveau de hiérarchie concerne les phases. Lorsqu'une phase est sélectionnée, et que l'onglet "functional diagram" 731 est sélectionné, on observe, dans la zone graphique 730, sous le nom de la phase, les noms des états qui lui correspondent, dans des rectangles.
Lorsque l'on clique sur la transition entre deux états, il est possible de sélectionner une opération élémentaire pour spécifier sa réalisation, c'est à dire la réalisation de la demande client correspondant à cette transition : cette opération élémentaire devra alors prendre en argument l'ensemble des données informatiques provenant de capteurs, d'actionneurs ou incidemment d'autres prestations nécessaires au calcul informatique qui sera réalisé pour décider si oui ou non la demande client est détectée. On accède ainsi aux traductions logicielles des demandes provoquant les transitions de phase.
Pour chaque état, par l'intermédiaire d'un menu contextuel apparaissant en cliquant sur l'état avec le bouton droit, on définit quelles opérations élémentaires doivent être activées (capture, commandes d'actionneur, lois de contrôle et leurs interfaces spécifiées dans d'autres outils tels que Matlab/Simulink, Statemate). On les regroupe ensemble selon différentes logiques ou pratiques du concepteur.
En cliquant, avec le bouton droit, sur une phase au quatrième niveau de la hiérarchie, on fait apparaître un menu contextuel qui permet, entre autres, de lier la phase aux modes (on observe, dans un menu contextuel une liste des modes, par exemple énergie, client, état du véhicule avec des cases à cocher pour associer la phase à des combinaisons des modes). Par exemple, la phase "crash" est spécifiée dans des modes où elle est valide. En sélectionnant un élément du cinquième niveau ("état"), toujours avec l'onglet
"functional diagram" 731 sélectionné, on observe, dans la zone graphique 730, la partie de l'automate concernant l'état sélectionné et les transitions (ou demandes) qui rejoignent l'état sélectionné et d'autres états. On peut ajouter, dans un état, des opérations élémentaires : séquence des opérations à effectuer (acquisitions, commandes, lois de contrôles, algorithmes), on clic droit sur l'état et on choisit "add" : on sélectionne dans une liste d'opérations élémentaires (bibliothèque métier).
On peut alors créer, si nécessaire, une nouvelle opération élémentaire à laquelle il faudra plus tard associer des données d'entrée et de sortie.
Au sixième niveau de hiérarchie, les opérations élémentaires sont organisées en groupes pour faciliter la navigation. Les groupes d'opérations comportent les mêmes opérations élémentaires pour tous les onglets horizontaux 611 à 616. Lorsque l'on sélectionne, au septième niveau de la hiérarchie, une opération élémentaire, on observe, dans la zone graphique 730, le flot de données (en anglais "data flow"), c'est-à-dire les données échangées par cette opération (données dans des rectangles en entrée et en sortie). Si on sélectionne un groupe d'opérations élémentaires, au sixième on observe, dans la zone graphique 730, le flot de données entre les opérations élémentaires qu'il comporte. Si on sélectionne un état, au cinquième niveau de hiérarchie, on observe, dans la partie graphique 730, le flot de données entre les groupes d'opérations élémentaires qu'il comporte. Pour chacun des cinquième à septième niveaux, si on sélectionne un lien dans la partie graphique, avec un clic sur le bouton gauche, on observe, dans un menu contextuel, une liste des données échangées. En en sélectionnant une, on peut la modifier (voir plus loin).
Lorsque l'on sélectionne une données, au huitième niveau de la hiérarchie, on observe, dans la zone graphique 730, toutes les opérations élémentaires qui la consomment et celles qui la produisent, y compris à l'extérieur de l'état, de la prestation, de la phase. Les éléments des neuvième et dixième niveaux de hiérarchie ("pilote" et
"composant") sont connus par ailleurs et proviennent de bibliothèque du constructeur du véhicule, d'équipementiers ou de fournisseurs.
Pour obtenir la différence entre les interfaces et contrôles de variantes de prestation sur deux véhicule différents par exemple, on sélectionne la prestation concernée dans la liste 720 avec un clic droit et on sélectionne, dans un menu contextuel, l'option "montrer les différences", en anglais "show différences". On sélectionne ensuite, dans une boîte de dialogue contextuelle, la variante de prestation d'un autre véhicule que l'on souhaite comparer à la variante de prestation déjà sélectionnée. Il apparaît alors , dans une boîte de dialogue contextuelle, une liste hiérarchisée Phase/Etat/Groupe d'opérations élémentaires/Opérations élémentaires/Données/Pilotes/Composants des deux prestations sélectionnées avec aux différents niveaux de ladite liste hiérarchisée que l'on sélectionne, un signe "+" lorsque seule la variante de prestation sélectionnée en premier comporte les éléments du niveau sélectionné, un signe "-" lorsque seule la variante de prestation sélectionnée en deuxième comporte les éléments du niveau sélectionné, un signe "I" s'il existe une différence à un niveau inférieur au niveau sélectionné, et aucun signe particulier si les deux listes hiérarchisées des variantes de prestation comparées sont identiques à ce niveau
Selon le niveau de l'élément de la liste hiérarchique sélectionné, on observe, dans la zone graphique 730, lorsque l'onglet "functional diagram" 731 est sélectionné : - nom du véhicule : liste des prestations,
- services ou prestations : la liste des variantes de prestation, variantes de prestation le graphe dont les nœuds sont les phases et les flèches orientées les demandes client de changement de phase, phase : l'ensemble des états dans un schéma tel que celui représenté en figure 7,
- état : le flot de données des groupes d'opérations élémentaires réalisées dans l'état, groupe d'opérations élémentaires : le flot de donnée des opérations élémentaires dans le groupe d'opérations élémentaires, opération élémentaire un graphe avec au centre l'opération élémentaire sélectionnée et autour d'elle les capteurs, actionneurs et autres opérations élémentaires de l'architecture dans son ensemble auxquels elle est liée les arrêtes du graphe sont les flots de données entre les nœuds. donnée : indiqué plus haut pilote : indiqué plus haut composant : indiqué plus haut
Pour passer à l'étape suivante de la conception de l'architecture du système de électronique et informatique de composants matériels et logiciel, le concepteur sélectionne ensuite l'onglet 732 "feature". Un des écrans qui correspond à cette sélection est illustré en figure 8. Dans cet écran, dont la partie texte 720 est identique à celle illustrée en figure 7, si on sélectionne une variante de prestation (troisième niveau de hiérarchie), on observe, dans la zone graphique 830, une enveloppe 840 de la variante de prestation.
Cette enveloppe 840 est représentée sous la forme d'une rectangle, divisée horizontalement en deux parties rectangulaires. La partie haute est reliée, à gauche, à des représentations des capteurs 851 qui lui fournissent des données et, à droite, à des actionneurs 852 et 853, auxquels la variante de prestation fournit des données. La partie basse est reliée, à gauche à des données entrantes 856 et 854 et, à droite, à des données sortantes 855. Les données qui ne font que transiter par la variante, sans être utilisées (ou consommées) ne sont pas représentées.
Si on clique, avec le bouton gauche, sur une donnée entrante, on observe, dans un menu contextuel, toutes les sources de la donnée sélectionnée, en termes d'opérations élémentaires. Dans cette représentation d'enveloppe 840, on utilise une formalisme permettant une vue synthétique des problèmes à régler : un point d'exclamation indique un conflit supposé (par exemple au cas ou, en sortie, plusieurs prestations prétendent fournir la même donnée) qui suppose de régler un problème d'arbitrage, un point d'interrogation en regard d'une donnée entrante pour laquelle aucun élément n'a encore été défini pour les produire.
Cette représentation d'enveloppe 840 donne une vue de synthèse très pratique pour l'utilisateur de l'outil de conception. Si, dans la représentation d'enveloppe, on clique sur une donnée, un capteur ou un actionneur, on obtient une vue fonctionnelle, indiquant les opérations élémentaires qui produisent la donnée et celles qui la consomme. Si l'on sélectionne ou clique sur une de ces opérations élémentaires, alors on voit dans un nouvel écran la liste des variantes de calculateur sur lesquelles cette opération élémentaire est placée. Cette affichage est réalisé dans une nouvelle fenêtre. Qui apparaît au moment ou l'on double clique. Si l'on clique sur un capteur ou un actionneur, on obtient la liste des variantes de prestation exploitant ce composant ainsi que la liste des variantes de calculateurs auxquels le composant est rattaché. Le retour à la normale s'effectue en fermant les fenêtres ainsi crées.
D'autre part, les prestations avec lesquelles la prestation sélectionnée échange des données apparaissent directement dans des boites comme 855 directement associées aux données d'entrée et de sortie de la prestation. Lorsque plusieurs prestations consomment ou produisent une donnée, alors ce n'est pas le nom d'une des prestations qui est affiché mais la séquence "..." et il faut cliquer sur la boite semblable à 855 pour voir s'afficher la liste des prestations dans une nouvelle fenêtre.
Lorsqu'une donnée est produite ou consommée par une opération élémentaire qui n'est pas rattachée à une prestation, alors on voit associé à la donnée, apparaître une icône spécifique 854. Dans certaines circonstances, par exemple lorsque l'on a récupéré la description des opérations élémentaires d'un calculateur mais que ces opérations élémentaires ne sont pas liées à une prestation, ce type de notation permet de savoir que l'opération élémentaire produisant la donnée G dans notre exemple est bien définie et placée. Pour passer à l'étape suivante de la conception de l'architecture du système de électronique et informatique de composants matériels et logiciels, le concepteur sélectionne ensuite l'onglet 613 "MAP" ou "feature architecture". Un des écrans qui correspond à cette sélection est illustré en figure 9.
Comme on l'observe en figure 9, l'interface utilisateur 900 de cet outil logiciel comporte alors :
- les menus déroulant 601 à 608, - les six onglets horizontaux 611 à 616,
- une zone de liste hiérarchisée 920,
- une zone graphique 930, et
- des onglets verticaux 931 et 932. Les onglets verticaux 931 et 932 sont nommés respectivement "networks" et
"feature" et sont accolés à la zone graphique 930. Ils servent à sélectionner un contenu à afficher dans cette zone graphique 930, comme exposé plus loin.
On observe, à gauche, la zone de liste hiérarchisée 920 qui comporte une partie de la liste dont les sept niveaux de hiérarchie les plus élevés sont : nom du véhicule services ou prestations variantes de prestation groupe d'opérations élémentaires opération élémentaire données pilote
Capteur/Actionneur Les trois niveaux de hiérarchie les plus élevés sont identiques à ceux des listes hiérarchisées 620 et 720 et, en particulier, comportent les services ou prestations. La sélection de l'un des composants de la liste hiérarchisée, par un clic gauche provoque, avec l'onglet "network" 931 sélectionné, l'apparition, dans la partie graphique 930, de l'ensemble des réseaux 941 à 943 de calculateurs 951 à 955, représentation synthétique permettant d'observer, pour l'élément sélectionné, sa répartition sur les calculateurs et les flots de données qui le concernent sur les réseaux. Selon le niveau de l'élément de la liste hiérarchique sélectionné, on observe, dans la zone graphique 930, lorsque l'onglet "network" 931 est actif l'ensemble des réseaux (les nœuds et les différents réseaux).
Chaque réseau est représenté avec tous les calculateurs qui y sont reliés, le réseau possédant une couleur spécifique, représentées ici par des gommettes, vignettes ou pastilles 961 à 963 portant des signes "+", "x" ou "o". Des calculateurs présents sur deux réseaux, calculateurs 951 et 955, sont, sur chaque réseau auquel ils sont reliés, dotés de "gommette(s)", chaque "gommette" possédant la couleur, représentée ici par le signe correspondant à chaque autre réseau auquel le calculateur en question est directement relié. Les gommettes donnent ainsi une vue en trois dimensions sans complexité de représentation.
En cliquant avec le bouton droit sur un réseau, on observe, dans une boîte de dialogue, la liste des données qui transitent sur ce réseau. Les icônes représentant les données, et qui sont suivis de leur nom en clair, apparaissent en vert sur fond blanc si la donnée en question n'est pas placée dans une trame circulant sur ce réseau, en bleu sur fond blanc lorsque la donnée est placée dans une trame et en bleu sur fond gris si la donnée n'est utilisée par aucun calculateur, que ce calculateur soit directement sur le réseau ou accessible par l'intermédiaire de calculateurs passerelles entre réseaux et d'autres réseau. Ces vues permettent une estimation de la charge du bus en durée moyenne entre deux transmissions de même donnée. Cette durée moyenne est estimée par exemple en tenant compte du protocole de communication mis en oeuvre sur le réseau considéré et affichée dans la fenêtre contextuelle et des performances de ce protocole, par exemple - le niveau de charge saturant le réseau (à partir de 30% de charge pour le CAN on observe que les trames les plus critiques peuvent ne pas arriver dans les temps voulus à cause du mécanisme d'arbitrage qui retarde la transmission d'une trame lorsque émission d'une autre trame de priorité supérieure ou égale a déjà été demandée, et la part de flot de donnée qui relève de la gestion de protocole (50% pour le CAN, typiquement car les données de gestion du protocole (arbitrage, CRC,...) représente pratiquement autant de bits en moyenne que les données effectivement transportées par une trame).
Le calcul du flot de données se fait par mode et on prend la charge la plus élevée dans le mode où elle apparaît. Cet aspect motivé par le fait que par exemple, en mode diagnostic, certaines trames correspondant à un mode client sont inhibées et donc ne sont pas en prendre en compte dans le calcul de charge. Réciproquement, le calcul de charge dans le fonctionnement pour le client final ne doit pas tenir compte des trames de diagnostic. Une trame soit émise dans un mode donné si et seulement si au moins une de ses données est échangée entre deux opérations élémentaires actives dans ce dit mode. Avec l'onglet 931 "network" sélectionné, l'utilisateur de l'outil peut effectuer le placement (en anglais "mapping") d'une variante de prestation ou d'un groupe d'opérations élémentaires, ou bien encore d'une opération élémentaire sélectionné dans la zone de liste 920, sur un ou plusieurs calculateurs représentés dans le partie graphique 930, par la fonction bien connue de "drag and drop" (que l'on peut traduire, en français, par "déplacer et lâcher"). A cet effet, lorsque l'on clique avec le bouton droit sur une variante de prestation ou une prestation, un menu contextuel apparaît et propose les différents types de placement.
Si une opération élémentaire existe dans plusieurs variantes de prestation, par exemple en figure 9 l'opération élémentaire "Décondamnation coffre" dans la liste hiérarchisée 920 qui est liée aussi bien à la "variante Badge" qu'à la "variante Clef", alors le fait de placer cette opération élémentaire par exemple sur le type de calculateur BFR, 953, au moment du placement de la variante de prestation "variante Badge" va aussi placer cette opération élémentaire pour la prestation "variante Clef" et même si ensuite la variante de prestation "variante Clef" est placée sur le type de calculateur UCH, seules les opérations élémentaires non encore placées seront placées sur le type de calculateur UCH, l'opération élémentaire "Décondamnation coffre" restant placée sur le type de calculateur BFR. Il en serait de même avec un groupe d'opération élémentaire d'une autre variante de prestation que "variante Badge" qui contiendrait l'opération élémentaire "Décondamnation porte" et que l'on placerait par exemple sur le type de calculateur UCH. De cette manière, les opérations élémentaires partagées entre plusieurs prestations ne sont placées qu'une fois. Par ailleurs, une fois qu'une opération élémentaire est placée, on peut annuler son placement et la replacer sur un autre type de calculateur en cliquant dans un menu obtenu en sélectionnant ladite opération élémentaire par un clic droit.
Les différents types de placement comportent, en particulier, le placement sur un seul calculateur, le placement en maître et esclave et le placement distribué. Dans le type de placement en maître-esclave, la partie "contrôle" de la prestation émet des messages de commande sur au moins un réseau pour commander chaque esclave et l'outil ajoute automatiquement ces messages de commande dans ou en dehors des trames déjà définies (voir plus loin). Pour pouvoir placer le maître et l'esclave, lorsque l'on sélectionne le type de placement maître - esclave, une opération élémentaire, représentant l'automate de contrôle de la prestation, est automatiquement ajoutée en relation avec la variante de prestation considérée. On l'appelle "opération élémentaire de contrôle". On place ensuite, par opérations de drag and drop, la variante de prestation, ou un groupe d'opération élémentaire ou une opération élémentaire et notamment l'opération élémentaire de contrôle sur une variante de calculateur. Il y a autant d'esclave que de nœuds sur lesquels l'opération élémentaire de contrôle n'est pas placée et sur lesquels au moins une opération élémentaire de la prestation est placée. Le nœud sur lequel l'opération élémentaire de contrôle de la prestation est placé est le nœud maître.
Avant de placer en maître et esclave, on commence par synthétiser l'opération de contrôle. Pour ce faire, on considère que cette opération consomme toutes les données permettant le calcul de l'automate de contrôle de la prestation. Par exemple, si une transition est conditionnée par la mise à un d'une donnée booléenne a, a étant le résultat d'une opération élémentaire, alors, dans le cas d'un placement maître - esclave, l'opération élémentaire de contrôle aura notamment a comme donnée d'entrée.
Le type de placement distribué signifie que des opérations élémentaires d'une même prestation sont réparties sur plusieurs calculateurs et que d'autre part, l'automate de contrôle de la prestation est synthétisé sur chacun desdits calculateurs. On ajoute donc automatiquement sur chaque nœud sur lequel on a placé au moins une opération élémentaire de la prestation au moment du placement une opération élémentaire de contrôle qui représente l'automate de contrôle de la prestation. Cette opération élémentaire de contrôle est la même que celle que l'on aurait synthétisée automatiquement pour un placement de type maître - esclave.
Pour chaque placement d'une prestation, une boîte de dialogue de placement apparaît pour demander si les opérations élémentaires, les capteurs et actionneur concernés doivent être placés simultanément et sur le même calculateur. Si on décide de placer la prestation avec les actionneurs et/ou capteurs concernés, l'outil de conception les connecte au calculateur. Si on ne place pas les opérations élémentaires, les capteurs et/ou les actionneurs sur le même calculateur que le reste de la prestation, l'outil de conception ajoute les données nécessaires au bon fonctionnement de la prestation dans ou en dehors des trames déjà définies (voir plus loin).
Si au moment du placement sur un nœud, c'est à dire sur un type de calculateur, plusieurs variantes de calculateur réalisent ce type de calculateur, alors une boite de dialogue apparaît pour demander sur lesquelles de ces dites variantes de calculateur le composant sélectionné doit être placé. Comme illustré en figure 10, si l'onglet "feature " 932 est sélectionné et que l'on sélectionne une variante de prestation (deuxième niveau de hiérarchie), on observe, dans la zone graphique 1030, placées les unes en dessous des autres, toutes les enveloppes 1061 et 1062 des types de calculateurs contenant au moins une opération élémentaire de la prestation sélectionnée. Seules les données d'entrée et/ou de sortie des opérations élémentaires de la variante de prestation sélectionnée contenus dans ces types de calculateur sont affichées ce qui permet de voir pour la dite prestation l'état d'avancement du placement et l'état des échanges internes et externes de la variante de prestation au sein de l'architecture électrique électroniques. Si des données telles que V2 ou V3 sont produites ou consommées par d'autres variantes de prestation, alors c'est indiqué avec les mêmes conventions qu'en figure 8 en zone 841.
On observe aussi, dans la zone graphique 1030, les mêmes deux types de calculateurs 1041 et 1042, correspondant respectivement à 1062 et 1061 sur lesquels est implantée la variante de prestation sélectionnée, ainsi que les flots de données qu'ils échangent. En cliquant sur l'une des flèches 1043 et 1044 représentant ces flots de données, on observe les données échangées dans une boîte de dialogue (non représentée). Dans ces boîtes on observerait les données V2 et V3 qui sont les seuls échanges internes à la prestation entre les types de calculateur UCH et BFR.
Si des trames de données étaient échangées, elles seraient représentées dans les enveloppes 1061 et 1062 à l'instar de la représentation en zone 1244 figure 12. Ces représentations graphiques sont mises à jour suivant les évolutions du placement des opérations élémentaires de cette variante de prestation Si l'onglet "feature " 932 est sélectionné et que l'on sélectionne un élément de l'un des quatrième à sixième niveau de hiérarchie, on observe, dans la zone graphique 1030, les flots de données (voir onglet "Func" 612 ci-dessus) mais pour tous les états confondus (il n'y a plus de niveau représentant les états dans la liste hiérarchisée 820). Les trois derniers onglets, 614 à 616, concernent le matériel avec une gestion de la diversité, c'est-à-dire des différentes variantes de réalisation matérielle du système.
Lorsque le concepteur sélectionne l'onglet 614 "operational architecture" ou "OPER", il accède à une description des opérations élémentaires de chaque calculateurs. On observe, en figure 11 , une interface utilisateur affichée lorsque l'onglet 614 "OPER" est sélectionné.
Comme on l'observe en figure 11 , l'interface utilisateur 1100 de l'outil logiciel comporte alors :
- les menus déroulant 601 à 608,
- les six onglets horizontaux 611 à 616, - une zone de liste hiérarchisée 1120, et
- une zone graphique 1130.
On observe, à gauche, la zone de liste hiérarchisée 1120 qui comporte une partie de la liste dont les six niveaux de hiérarchie les plus élevés sont : nom du véhicule type de calculateur variante de calculateur prestation opération élémentaire données pilote
Capteur ou actionneur Selon le niveau de l'élément de la liste hiérarchique sélectionné, on observe, dans la zone graphique 1130 : type de calculateur Le flot de données entre les différents nœuds du réseau indépendamment de l'implémentation de ce flot en trames ou réseaux de toutes sortes. Si une opération élémentaire placée sur un nœud consomme une donnée produite par une autre opération élémentaire sur un autre nœud, alors la donnée échangée apparaît dans le flot de donné matérialisé graphiquement par une flèche allant du nœud où les données sont produites vers le nœud où les données sont consommées. variante de calculateur Le graphe orienté dont les nœuds sont les opérations élémentaires placées sur la variante de calculateur, 1140, 1142, 1144, 1146, 1148 et les flèches sont les flots de donnés entre ces opérations élémentaires comme par exemple 1162.
Opération élémentaire les liens aux capteurs et actionneurs liés à l'opération élémentaire sélectionnée et montés sur le calculateur données les opérations élémentaires, capteurs ou actionneurs auxquels la donnée est liée directement sont affichés dans un graphe. Les capteurs ou opérations élémentaires qui produisent la donnée apparaissent à sa droite alors que les actionneurs ou opérations élémentaires consommant la donnée sont placés à gauche de la donnée. Les flèches indiquent le sens de passage de la donnée (du producteur vers le consommateur). - Pilote les caractéristiques du pilote, type d'entrée/sortie analogique-numérique, tout-ou-rien, ses caractéristiques électriques. - Capteur/actionneur un graphe avec au centre le capteur ou l'actionneur sélectionné et autour de lui les opérations élémentaires de l'architecture dans son ensemble auxquels il est lié, les arrêtes du graphe sont les flots de données entre les nœuds. On observe, en figure 12, une interface utilisateur affichée lorsque l'onglet 615 "hwd" ou "hardware architecture" est sélectionné.
Comme on l'observe en figure 12, l'interface utilisateur 1200 de l'outil logiciel comporte alors :
- les menus déroulant 601 à 608,
- les six onglets horizontaux 611 à 616,
- une zone de liste hiérarchisée 1220,
- une zone graphique 1230, et - les onglets verticaux 1232 et 1234.
On observe, à gauche, la zone de liste hiérarchisée 1220 qui comporte une partie de la liste dont les six niveaux de hiérarchie les plus élevés sont : nom du véhicule type de calculateur variante de calculateur trames donnée dans la trame capteur / actionneur données pilote Selon le niveau de l'élément de la liste hiérarchique sélectionné, on observe, dans la zone graphique 1230, lorsque l'onglet "networks" 1232 est sélectionné : nom du véhicule les réseaux de cette architecture véhicule type de calculateur les réseaux auxquels ce type de calculateur est connecté, représenté en figure 16 variante de calculateur les réseaux auxquels cette variante de calculateur est connectée trames ou le réseau auquel cette trame appartient donnée dans la trame le réseau auquel cette donnée appartient (via la trame) capteur / actionneur le type de calculateur auquel est connecté ce composant et les réseaux sur lesquels ce type de calculateur est connecté. Données Rien Pilote Rien et, lorsque l'onglet "Diagrams" 1234 est sélectionné : nom du véhicule Rien type de calculateur Un graphe dont les nœuds sont les types de calculateur et dont les flèches sont les flots de trame, les flèches étant orientées du nœud émetteur vers le nœud récepteur. variante de calculateur affichage comme définit en figure 12 par le contour 1260 découpé en trois parties 1240, 1242 et 1244 par deux traits horizontaux 1262 et 1264.
Dans la zone 1240, les liens de la variante de calculateur à des capteurs ou des actionneurs sont affichés, les liens aux capteurs étant affichés d'un côté 1252 et les liens aux actionneurs étant affichés de l'autre côté 1250, 1254. Dans le diagramme, dans le cas d'une saisie d'information provenant d'un capteur 1252, la donnée apparaît à l'intérieur du contour 1260, alors que le nom du capteur "Clef" apparaît à l'extérieur du contour. De cette manière le concepteur peut distinguer facilement les noms des données du logiciel applicatif embarqué sur la variante de calculateur, des noms des différents capteurs et actionneurs, et de plus le lien des capteurs/actionneurs aux données logiciels est clair. Dans la zone 1244 est représentée Pinterfaces messagerie de la variante de calculateur sélectionnée. Cette interface messagerie est constituée de trames de message consommées ou produites sur les divers réseaux auxquels est connectée la variante de calculateur sélectionnée. Les trames consommées sont représentées d'un côté de la zone, et les trames sortantes de l'autre côté. Par exemple T_in_1, 1246, est une trame entrante et T_out_1 et T_out_2, respectivement 1247 et 1248, sont des trames émises. Seules les données effectivement consommées et produites par au moins une opération élémentaire sur la variante de calculateur sélectionnée sont représentées en zone 1244 en correspondance avec les différentes trames. Par exemple, si un emplacement pour une donnée "n" est réservé dans T_in_1 et si la donnée "n" n'est consommée par aucune opération élémentaire sur la variante de calculateur sélectionnée, alors, "n" n'apparaît pas en zone 1244.
Réciproquement, la donnée "a" qui apparaît en correspondance de T_in_1 est donc consommée par une opération élémentaire placée sur la variante de calculateur sélectionnée. Finalement, en zone 1242, on retrouve les données d'entrée et de sorties du calculateur sélectionné qui ne sont ni liées à des capteurs / actionneurs, ni à des trames, et qui pourtant proviennent ou sont à destination d'autres nœuds. On reprend pour cette zone
1242 les conventions de la zone 841. Finalement, les données qui ne font que transiter par la variante de calculateur sélectionnée, qui fait alors office de passerelle entre réseaux, sont accessibles sous forme d'une liste en sélectionnant un onglet du menu 603. La séparation des données en deux catégories, non encore affectées et déjà affectée fournit une vue de cohérence de ce qui est fait et de ce qui reste à faire.
Trames rien donnée dans la trame opérations élémentaires et/ou capteur/actionneurs producteurs ou consommateurs à l'intérieur de la variante de calculateur sélectionnée. capteur / actionneur un contour rectangulaire (non représenté) séparé en deux parties, la partie du dessus servant à indiquer les données produites par le capteur/actionneur à l'aide d'un pilote et utilisées sur d'autres calculateur que celui auquel le composant est rattaché, la parties inférieure servant à représenter les données produites à l'aide d'un pilote et utilisées sur le calculateur auquel le composant est rattaché. Les données reçue par le composant sont sur la gauche du contour alors que les données émises sont sur la droite du contour. Un tel lien donnée-calculateur est représenté de manière similaire au lien donnée-prestation 855 en Figure 8, si ce n'est que si la même donnée est par exemple émise vers plusieurs calculateurs, alors, elle sera répétée plusieurs fois, ce qui est une alternative à un affichage du type "..." avec une boite sur laquelle il faudrait cliquer pour accéder aux différentes variantes de calculateurs, autres que celui auquel le composant est rattaché, utilisant la donnée. données d'un capteur ou actionneur opérations élémentaires et/ou capteur/actionneurs producteurs ou consommateurs à l'intérieur de la variante de calculateur sélectionnée. Pilote comme pour la donnée, voir ci-dessus.
Lorsque l'onglet "networks" 1232 est sélectionné, on observe, dans la partie graphique 1230, l'architecture matérielle et le placement de calculateurs sur des réseaux. Chaque réseau est représenté avec tous les calculateurs qui y sont reliés, le réseau possédant une couleur spécifique, représentées ici par des gommettes portant un signe "+", "x" et "o" comme en Figure 9. Des calculateurs présents sur deux réseaux sont, sur chaque réseau auquel ils sont reliés, dotés de "gommette(s)", chaque "gommette" possédant la couleur, représentée ici par un signe "+", "x" ou "o" des autres réseaux auxquels le calculateur en question est directement relié. Les gommettes donnent ainsi une vue en trois dimensions sans complexité de représentation. Lorsque l'on effectue un clic droit sur un réseau, il apparaît, dans une boîte de dialogue contextuelle, une liste des données circulant sur ce réseau. Dans cette boîte de dialogue, des couleurs différentes indiquent les données qui ne sont pas allouées dans une trame, celles qui sont allouées et transitent effectivement dans une trame et celle qui sont allouées mais ne transitent pas effectivement parce que par exemple elle ne sont pas produite.
Les données circulant sur un réseau sont visibles dans une boîte de dialogue lorsque l'on clique avec le bouton droit sur le réseau en question, l'onglet "networks" 1232 ou 1232 étant actif. Cette boîte de dialogue met en oeuvre des couleurs pour indiquer le placement dans une trame et l'utilisation des données, comme expliqué plus haut, en regard de la figure 9.
Lorsque l'onglet 616 est sélectionné (écran non représenté), si on sélectionne une donnée en cliquant sur le bouton gauche, un menu surgissant permet d'atteindre une boîte de dialogue contextuelle qui fournit des informations sur cette donnée, notamment, la dimension (un booléen à une taille de un bit), les valeurs extrêmes, une valeur par défaut et l'âge maximal de la donnée c'est à dire durée après la capture au bout de laquelle la donnée peut être considérée comme obsolète... etc .
Lorsque l'on sélectionne l'onglet 616 "msg", on obtient en partie droite un écran analogue à celui de la figure 16, lorsque l'onglet 1232 de la figure 16 est sélectionné. On voit alors en partie droite de l'écran pour chaque véhicule toutes les trames véhiculées par moins un réseau et en partie gauche de l'écran une représentation des différents réseaux comme en figure 16 en zone 1630 . En cliquant sur une trame, seul le réseau sur lequel la trame circule est affiché. En cliquant sur l'un des onglets 1652, 1654, 1656, 1658, seules les trames circulant sur le réseau correspondant sont affichées en partie gauche de l'écran, lorsque l'onglet 1231 est sélectionné, lorsque l'on clique sur une trame, une présentation de la trame en partie droite de l'écran apparaît reprenant les informations essentielles de la trame, notamment sa taille, sa période, le type du réseau, puis la liste des données pour lesquelles un espace est alloué ainsi que les coordonnées de cet espace en numéro d'octet et de bit le plus significatif et en taille, puis la liste des variantes de calculateur producteur et consommateur pour chaque donnée. Dans la zone graphique correspondant à la sélection de l'onglet 616, si on clique avec le bouton gauche sur un calculateur, on observe, par l'intermédiaire d'un menu surgissant donnant le choix entre trame et données, dans une boîte de dialogue contextuelle, les données ou trames consommées ou produites par le calculateur sélectionné.
La figure 13 représente un écran 1300 de saisie et de visualisation des zones d'un produit nommé "véhicule Z23" pour lequel on souhaite construire une architecture électrique et électronique. On peut accéder à cet écran à partir de n'importe lequel des écrans des figures 6 à 12 par une sélection dans le menu tools 606.
On observe, dans la liste hiérarchisée 1320, une liste comportant les trois premiers niveaux de hiérarchie suivants : nom de véhicule groupes de noeuds et composants noeuds et composants La partie graphique, à droite de l'écran, comporte une zone supérieure dans laquelle trois boutons 1312, 1314 et 1316 sont représentés. Les différentes zones du véhicule sur lesquelles les composants du système peuvent être placés apparaissent dans la partie graphique inférieure droite de l'écran, ou sous-écran 1330. Ces zones du véhicule sont représentées par des rectangles 202, 204, 206 236, 240. Pour ajouter une zone, l'utilisateur doit d'abord sélectionner le bouton 1312 placer ce rectangle, qui correspond à une nouvelle zone du véhicule, en cliquant dans le sous-écran 1330. Il peut alors changer les dimensions dudit rectangle, par exemple en cliquant sur un des angles du rectangle, puis en déplaçant cet angle à volonté, l'angle opposé dudit rectangle ne bougeant pas. Il peut ensuite déplacer le rectangle à volonté dans le sous-écran 1330, afin de rendre la disposition des zones respectives compréhensible pour l'ensemble des utilisateurs. Dans le cas d'un véhicule automobile par exemple, il ne serait pas sensé de placer la zone représentant la porte arrière droite et la zone représentant la porte avant gauche l'une à côté de l'autre.
Le nom 1342 du produit est repris en bas du sous-écran 1330. On note que les nœuds et composants définis pour l'outil de conception sont repris dans la liste hiérarchisée 1320. En fait, cette liste hiérarchisée sert une fois que les différents composants sont placés: sélectionner un nœud ou un calculateur particulier permet de localiser dans quelle zone du véhicule il est placé, cette zone changeant automatiquement d'aspect dans le sous-écran 1330. Par exemple, lorsque dans la liste hiérarchisée, on sélectionne la pédale d'accélération 1321 , la zone cockpit 218 change d'aspect.
D'autre part, les composants non encore placés ont eux aussi un aspect particulier comme par exemple le nœud BVA 1323 ou le moteur d'essuyage avant 1322.
En sélectionnant le bouton 1316, il est possible de rajouter, dans le sous- écran 1330, une boussole orientable 1344 à des fins de lisibilité pour l'ensemble des utilisateurs. Il revient à l'utilisateur d'indiquer lesquels des axes (gauche, droite), (haut, bas), (avant, arrière) doivent être utilisés ainsi que leur sens. Dans la figure 13, dans le cas d'un véhicule automobile dont des zones, vue de haut, ont été représentées, l'orientation permet à l'homme du métier de reconnaître certaines de ces zones, comme par exemple le pavillon 216, puis de proche en proche, l'ensemble des zones représentées. Afin de rendre ce découpage en zones plus lisible, il est possible de nommer les zones. C'est par exemple le cas de l'aile avant droite nommée Aile AVD 1346.
La figure 14 représente une vue locale d'une des zones du véhicule représentées dans la figure 13 dans le sous-écran 1330 de l'écran 1300. On y accède, par exemple, en sélectionnant la dite zone dans le sous-écran 1330 puis en cliquant deux fois.
Dans le sous-écran 1330, on peut préciser les dimensions de la dite zone en sélectionnant le bouton 1410 puis en sélectionnant l'un des sommets de la dite zone et en le bougeant à volonté, les autres sommets restant inchangés. Sélectionner un point du contour de la zone autre qu'un sommet permet de définir un nouveau sommet. On peut spécifier une sous-zones d'évitement en sélectionnant un bouton 1412 puis l'emplacement de la zone où l'on désire placer la sous-zone d'évitement. La sous-zone d'évitement est alors placée sous forme d'un rectangle avec des dimensions par défaut. Le dimensionnement exact de la sous-zone se fait alors, comme pour la zone du véhicule, en sélectionnant un bouton 1410 puis en sélectionnant l'un des sommets de la sous-zone d'évitement sélectionnée ou en rajoutant un sommet. En sélectionnant un point du contour autre qu'un sommet.
Les points de routage sont placés sur la zone en sélectionnant d'abord un bouton 1414 puis en sélectionnant l'endroit de la zone où l'on désire placer le dit point de routage. Les points de connexion de la zone sont placés en sélectionnant d'abord le bouton 1416 puis en sélectionnant l'endroit de la zone où l'on désire placer le dit point de connexion. Comme en figure 14, une boussole peut être placée à côté de la zone en sélectionnant le bouton 1316, puis orientée.
Un chemin de routage recommandé peut être placé en sélectionnant un bouton 1418, puis en sélectionnant un composant ou point de routage ou point de connexion initiale, puis un composant ou un point de routage ou un point de connexion finale.
Les composants et calculateurs sont placés sur la zone par cliquer-déplacer à partir de la liste hiérarchisée 1420. Ils peuvent être associés à des icônes qui permettent de les localiser et de les reconnaître plus rapidement.
Tous les éléments de la zone du véhicule représentée peuvent être déplacés et ajustés par cliquer-déplacer. Finalement, un élément "règle" peut être placé dans la fenêtre pour faciliter le dimensionnement des différents zones. Pour cela, on sélectionne un bouton 1413, puis on sélectionne l'endroit de la zone où l'on désire placer la règle. En sélectionnant l'une des extrémités de la règle 1444, on peut l'étendre ou la raccourcir. Au moment où l'on effectue cette opération, la longueur réelle de la règle est affichée, par exemple en millimètres.
Il est possible de faire pivoter la règle autour d'un de ses sommets suivant des moyens connus. Placer la règle à côté d'un des bords de la zone permet d'en connaître la longueur et de changer éventuellement son dimensionnement.
Toujours avec l'objectif d'une représentation la plus fidèle possible, dans le sous- écran 1430, il est possible de faire apparaître une trame de fond permettant de représenter la zone à la bonne échelle. La trame de fond peut par exemple être constituée de traits horizontaux et verticaux parallèles et réguliers, découpant l'espace en pavés de 20mm par 20mm dans l'échelle 1:1.
Il est possible d'agrandir et de rétrécir la zone du véhicule représentée pour le confort d'utilisation, c'est à dire changer l'échelle de la figure pour qu'elle soit adaptée à la partie du sous-écran 1430 par des moyens connus appelés zooms. La zone et tous les éléments placés sur l'écran changent alors d'échelle.
Une fois l'opération de placement des points de connexion effectuée sur différentes zones, on peut revenir à la vue présentée en figure 13 pour lier les points de connexion des différentes zones du véhicule qui se correspondent dans le sous écran 1330. Dans un certain mode d'affichage, accessible par le menu "View" 603, les points de connexion spécifiés dans la zone 202, par exemple, apparaissent. Cette zone contient trois points de connexion 1350, 1351, 1355. La zone 220 contient, elle, pour le moment, un point de connexion 1353. Pour indiquer par exemple que les points de connexions 1355 et 1353 se correspondent c'est à dire représentent en fait un même point dans l'espace, on peut par exemple sélectionner le bouton 1314, puis sélectionner le point de connexion 1355, puis sélectionner le point de connexion 1353. Un lien graphique 1354 est alors automatiquement généré. Une nouvelle sélection du menu "View" 603, permet, si on le souhaite, de cacher tous les points de connexion et leurs liens.
Il est possible de nommer les points de connexion, comme cela est fait par exemple pour le point de connexion "C3" 1448 . Dans ce cas, le nom du point de connexion est repris dans le sous-écran 1330, lorsque l'option d'affichage des noms des points de connexion est activée.
En sélectionnant, dans le menu "Edit" 602, l'option "Synthèse du câblage", l'algorithme de routage est exécuté. On peut ensuite visualiser le résultat. En figure 14, les segments 1451 à 1455 sont synthétisés. En cliquant sur chacun de ces segments, on obtient la liste des liens ou fils composant-composant, ou composant-connecteur ou connecteur-composant qui sont inscrit dans chacun de ces segments. Par exemple, si le moteur 406 possède un connecteur à trois pines, l'une de commande, faible puissance, l'une d'alimentation forte puissance, la troisième de masse, on obtient la liste suivante :
Moteur- 1 -donnée de commande moteur 406 Moteur- 2 - alimentation moteur 406
Moteur- 3 -masse moteur 406
Si ces trois pines, lors du routage, sont associées à trois pines du connecteur C1 1447, respectivement, on observe la liste suivante :
C1- 3 -donnée de commande moteur 406 C1- 5 - alimentation moteur 406
C1 - 1 -masse moteur 406
Alors, en cliquant sur le lien 1452, on voit s'afficher que, sur le segment entre les points de routage 1470 et 1472 circulent les liens de référence :
Moteur- 1 -donnée de commande moteur 406 ; C1 - 3 -donnée de commande moteur 406
Moteur- 2 - alimentation moteur 406; C1- 5 - alimentation moteur 406
Moteur- 3 -masse moteur 406; C1- 1 -masse moteur 406
La figure 15 représente l'écran qui apparaît lorsque l'on sélectionne le "Véhicule Z23" et que l'onglet "Func" 612 est sélectionné. On obtient alors en partie graphique 1530, à droite de l'écran, un graphe dont les nœuds sont les variantes de prestation et les flèches les flots de données échangés entre les variantes de prestation. Un tel flot de données représenté par une flèche entre une variante de prestation de départ et une variante de prestation d'arrivée est défini par l'ensemble des données produites par au moins une opération élémentaire de la variante de prestation de départ, qui ne sont produites par aucune opération élémentaire de la variante de prestation d'arrivée, mais qui sont consommées par au moins une opération élémentaire de la variante de prestation d'arrivée.
Le flot de données inter-prestation tel que représenté en figure 15 est généré pour un choix d'une variante de prestation pour chaque prestation correspondant à une configuration. Pour l'homme du métier, ces flots de données permettent de repérer les données pour lesquelles des précautions sont à prendre pendant le développement. En effet, les données entre prestations et leurs caractéristiques doivent être validées pour chaque prestation les consommant ou les produisant au contraire des données intrinsèques à une prestation dont la mise au point relève uniquement de la dite prestation.
On peut, dans l'écran illustré en figure 15, représenter l'intégralité des échanges entre toutes les prestations du produit ou les échanges d'un sous ensemble de prestations, cela en copiant dans une architecture produit par exemple créée pour l'occasion, le dit sous ensemble de prestations et en considérant le graphe correspondant dans la partie graphique 1530.
La figure 16 représente un écran apparaissant lorsque l'on sélectionne l'onglet "HWD" 615, l'onglet "Network" 1232, et le nœud UCH 1621 dans la liste hiérarchisée 1220. On voit alors apparaître, dans la partie graphique 1630, une vue de réseau répondant aux mêmes conventions que la vue décrite en partie graphique 830 illustrée en figure 8. Seules les réseaux sur lesquels le nœud UCH 1621 est présent sont alors affichés, à la différence de ce qui est représenté en figure 8 où tous les réseaux sont affichés. Des onglets dans une zone 1640 permettent de sélectionner les différents réseaux de l'architecture 1654, 1656, 1658. La sélection de l'onglet "ail" 1652 permet de provoquer l'affichage dans la partie graphique 1630 de tous les réseaux et annule la sélection du nœud UCH 1621.
En cliquant sur un réseau donné, on obtient l'ensemble des données qui circulent sur ce réseau en distinguant notamment celles qui ne sont pas provisionnées dans des trames, celles qui sont provisionnées et présentes, celles qui sont provisionnées et absentes. En figure 17, le procédé de conception de spécification d'une variante de prestation est détaillé.
Les étapes 1712 et 1714 sont des synthèses réalisées automatiquement pour l'outil alors que toutes les autres étapes sont assistées grâce à l'ergonomie de l'outil mais sont laissées à l'initiative du concepteur. Lors de la conception de la spécification d'une variante de prestation, en premier lieu on spécifie les cas d'utilisation, étape 1702. Une fois les cas d'utilisation spécifiés, on identifie les phases de fonctionnement, les demandes client qui sont les transitions et les réponses système qui sont les états, étape 1704. Les phases sont définies préférentiellement par leur décomposition en modes transversaux comme ceci est présenté en figure 7. Deux phases ne doivent préférentiellement pas partager de combinaison de modes transversaux. On peut alors synthétiser un premier automate décrivant la supervision de la prestation tel que détaillé en figure 7 . Pour cela, on part de l'association proposée par l'utilisateur des cas d'utilisation aux triplets (état de départ, demande client, état d'arrivée).
A partir de cette ces premières étapes supportées par l'onglet REQ de l'outil, un automate de contrôle de la prestation est synthétisé automatiquement pour l'ensemble des cas d'utilisation de la prestation, étape 1712.
On procède alors aux étapes de correction, étape 1714, et complétion, étape 1716, qui permettent de mettre au point l'automate et d'enrichir les cas d'utilisation, étape 1720, en fonction de nouvelles situations identifiées notamment lors de l'étape de complétion, étape 1716. Parallèlement aux étapes de mise au point de l'automate de contrôle de la prestation, étapes 1712, 1714 et 1716, on spécifie les opérations élémentaires réalisées dans chacun des états de l'automate de contrôle de la prestation, étape 1706.
De même, certaines opérations élémentaires réalisant les transitions de phase sont identifiées, étape 1708, ainsi que les opérations élémentaires réalisant les demandes client, étape 1710. La réalisation d'une transition de phase ou d'état par une opération élémentaire est représentée préférentiellement par une opération élémentaire dont le résultat est un booléen qui lorsqu'il vaut la valeur booléenne "vrai" résulte en l'activation de ladite transition. On peut de manière équivalente, mais pour plus de généralité, spécifier que la transition opère pour une valeur particulière d'une des sorties de l'opération élémentaire qui la réalise. Lorsque les étapes 1706, 1708 et 1710 sont partiellement ou complètement réalisées, on synthétise le flot de données entre les opérations élémentaires spécifiées au cours de ces étapes, étape 1718.
On peut alors synthétiser un modèle de la variante de prestation spécifiée, étape 1722, en complétant notamment l'automate synthétisé au cours de l'étape 1712 et les différentes opérations élémentaires qui lui sont attachées avec la description de capteurs et actionneurs préférentiellement attachés à la prestation et des pilotes correspondants.
La figure 18 décrit un procédé de conception d'architecture électrique et électronique permettant de comprendre les interactions entre les différentes étapes du procédé décrit dans l'invention, mais aussi les différentes vues proposées par l'outil.
Comme point de départ, une spécification des configurations du produit est spécifiée par l'utilisateur, étape 1802. Elle indique les différentes configurations caractérisées notamment par un ensemble de variantes de prestation et un ensemble de variantes de calculateurs. Pour chaque configuration, un pourcentage est indiqué correspondant au rapport du nombre de produits comportant ladite configuration par le nombre produit total. Cette étape étant réalisée, une spécification de chaque variante de prestation est réalisée, étape 1806, notamment en appliquant le procédé décrit en figure 17. On peut alors procéder automatiquement aux validations de l'architecture prestation, étape 1808 (décrites plus loin). Pour un ensemble de configurations, spécifiées au cours de l'étape 1802, on spécifie un ensemble de nœuds et de réseaux les connectant et pour chaque nœud un ensemble de variantes de calculateurs, étape 1810. D'autre part, la géométrie du produit est spécifiée, étape 1804. Une fois les étapes 1806 et 1810 partiellement ou complètement réalisées, on peut placer les prestations sur les différents nœuds, étape 1812. On réalise alors automatiquement une synthèse du contrôle des prestations, étape 1816, ainsi que la synthèse des échanges, notamment sur les différents bus de données, étape 1818. A partir des échanges sur les bus, étape 1818, on peut spécifier une messagerie ou la générer automatiquement, étape 1826, par exemple au moyen du procédé décrit dans la demande de brevet français numéro 01-05713 du 27 Avril 2001 incorporé ici par référence.
D'autre part, les différentes variantes de calculateur, spécifiées au cours de l'étape 1810, et les différents capteurs et actionneurs, notamment rattachés aux variantes de prestation, spécifiées au cours de l'étape 1806, sont placés sur la description géométrique du véhicule, étape 1814. On place de même les points de routage, de connexion, les connecteurs et les zones d'évitement, étape 1820.
A partir du placement des différents composants électriques et électroniques, étape 1814, et de la description des contraintes géométriques, étape 1820, on synthétise le routage des signaux notamment de données, de puissance ou liés à la masse, étape 1822.
On spécifie d'autre part les caractéristiques des différentes opérations élémentaires en termes de taille de code, de taille mémoire vive nécessaire et de consommation CPU, étape 1824. Etant donnés le routage, étape 1822, d'une part, et la spécification des ressources nécessaires à l'exécution des composants logiciels qui réalisent les opérations élémentaires, étape 1824, d'autre part, on déduit une estimation de coût du système basé sur le coût de l'architecture électrique (capteurs, actionneurs, fils, connecteurs) et le coût lié aux types d'entrées - sorties et aux choix de processeurs induits par le placement, étape 1830, Cette synthèse, étape 1830, est réalisée en prenant notamment en compte l'optimisation induite par des épissures sur les fils de puissance et de masse, étape 1828. Finalement, toutes ces étapes étant réalisées, on peut comparer l'architecture évaluée à d'autres architecture, notamment par un critère de coût, de qualité ou de poids notamment par un critère de coût consolidant notamment les critères de qualité et de poids, étape 1832. Afin de réaliser une estimation de qualité consolidée, il faut réaliser plusieurs étapes:
- calculer automatiquement une mesure de qualité pour l'exécution d'une opération élémentaire, et pour l'exécution d'un ensemble d'opérations élémentaires sur un calculateur, étant donnée une mesure de qualité pour chaque type d'entrées/sorties, pour chaque type de fil (puissance, masse, données), et étant donnée une mesure de qualité pour l'exécution d'une instruction sur un calculateur, pour un accès en mémoire vive, pour un accès en mémoire flash,
- calculer automatiquement la qualité du routage
- prendre en compte une mesure de qualité des capteurs et actionneurs
- déduire automatiquement la qualité de l'architecture électrique et électronique Les opérations de validation et leur support par des moyens de traçabilité, la maîtrise de la sûreté de fonctionnement ne sont pas décrits en figure 18 mais complètent cette figure reprenant le procédé global.
En ce qui concerne les configurations, on peut distinguer : - les prestations de base qui peuvent être réglementaires ou banalisées sur les véhicules (éclairage, essuyage des vitres,...),
- les prestations de base avec variante comme par exemple la motricité sur un véhicule qui peut être basée sur un moteur thermique essence ou diesel, sur un moteur électrique ou sur un moteur hybride par exemple, avec à chaque fois une mise en œuvre différente,
- les prestations qui ne seront pas nécessairement intégrées à tous les produits et que l'on peut qualifier d'optionnelles. Par exemple la climatisation sur une automobile,
La configuration de prestation est la sélection d'un ensemble de variantes de prestations (optionnelles ou pas). Les prestations optionnelles de la configuration sont celles qui ne sont pas toujours présentes.
Pour une configuration donnée, on donnera le taux de monte des prestations optionnelles notamment sous la forme d'un pourcentage.
Pour un produit donné, on envisagera différentes configurations. Considérant l'ensemble des configurations, on donnera le pourcentage respectif de chaque configuration par exemple sous la forme d'un pourcentage.
Par exemple pour une automobile, on distingue les configurations luxe, confort,
"éco" (pour "économique") avec par exemple une prestation climatisation à 100% sur la configuration luxe, 40% sur la configuration confort et 0% sur la configuration éco. Les configurations luxe, confort, éco pourront représenter respectivement 20% 50% et 30%. Les configurations prévues pour un produit ont un impact sur le choix de l'architecture matérielle du produit. Par exemple, une climatisation à faible taux de monte
(10%) incitera à mettre en œuvre cette climatisation à l'aide d'un calculateur spécifique alors que si la climatisation est présente à 100%, on aura tendance à intégrer le logiciel et les interfaces matérielles correspondants à un calculateur agglomérant de nombreuses autres prestations. Il est en effet coûteux de multiplier le nombre de calculateurs électroniques et l'on cherche en pratique à intégrer le plus possible de prestation pour faire baisser les coûts.
Les configurations servent aussi à faire des choix de câblage, l'exemple de la climatisation ci-dessus le montre bien puisque le câblage pour un calculateur spécifique aura un coût différent du câblage pour un calculateur non-optionnel. Le choix d'un optimal de l'architecture électrique-électronique se fait donc préférentiellement en fonction d'un ensemble de configurations pré-défini. Les configurations servent aussi à gérer la diversité en permettant de limiter par conception, les combinaisons d'option disponibles.
Elles représentent aussi un élément intermédiaire permettant de simplifier les validations comme on le verra par la suite. De par l'étape de placement des prestations sur les calculateurs, On peut déduire les configurations de calculateur associées à une configuration prestation. Ce sont notamment les calculateurs contenant au moins une opération élémentaire d'au moins une prestation de la Configuration prestation. Le caractère optionnel du calculateur est aussi déduit, un calculateur contenant notamment des opérations élémentaires attachées uniquement à des prestations optionnelles pourra être optionnel.
Pour autant, on peut définir des configurations de calculateur et de composants matériels, notamment si l'étape de placement n'est pas encore réalisée.
Lorsque l'on spécifie une configuration comme étant composée d'une configuration de prestation et d'une configuration de calculateurs, on fait l'hypothèse que toute prestation de la configuration de prestation est bien entièrement placée sur la configuration de calculateur et que réciproquement, les opérations élémentaires provenant de prestations qui ne sont pas dans la configuration de prestation sont désactivées sur ladite configuration de calculateurs.
On intègre dans le choix d'un routage optimal une contrainte liée aux configurations. Un composant dont au moins une variante est absente dans au moins une configuration est dit optionnel. Le routage économiquement optimal est, par exemple celui qui satisfait les contraintes suivantes:
• 1) on ne peut pas lier un composant (capteur, actionneur) à un noeud optionnel tel qu'il existe au moins une configuration où le nœud est absent et le composant est présent. Donc dans la recherche du routage dudit composant, les nœuds ne satisfaisant pas le critère ci-dessus ne sont pas considérés.
• 2) on ne peut pas lier dans une épissure de puissance deux fils qui ne seraient pas présents dans les mêmes configurations.
• 3) sous l'hypothèse 1) ci-dessus, lorsque l'on synthétise le routage d'un fil provenant d'un composant optionnel C et que le routage optimal abouti à un nœud Nn tel qu'il existe au moins une configuration où le nœud Nn est présent et le composant C est absent, alors on tente de synthétiser au moins un autre routage en considérant tous les nœuds autres que Nn qui satisfassent la condition 1). Le routage lie alors le composant à un nouveau nœud Nn+1. On itère cette opération jusqu'à trouver un nœud Np tel que soit Np est le dernier nœud parcouru qui satisfasse 1). Pour l'ensemble des routages ainsi synthétisés (le dernier étant le routage à Np), on applique le calcul de coût pondéré par le taux de monte des différents composants, c'est à dire qu'un composant présent dans 40% des configurations aura un coût pondéré par 0,4. Le routage qui minimise le coût est le routage économiquement optimal pour l'ensemble des configurations.
Par exemple, on peut rattacher le compresseur de la climatisation au noeud climatisation (optionnel et spécifiquement installé pour la prestation climatisation) ou au nœud calculateur habitacle (toujours présent). La connexion au nœud climatisation coûte deux euros intégrant par exemple le coût du connecteur du calculateur pour la connexion au compresseur et aux autres composants soit un euro, le coût des fils soit un euro, et un euro sur le contrôleur habitacle . Si le taux de monte de la clim dépasse 50%, alors il faut router le compresseur au nœud contrôleur habitacle, sinon au noeud climatisation. Par exemple avec un taux de monte de 40% et pour cent exemplaires, le routage au nœud habitacle coûte 1*100 * 1 euro soient cent euros, alors que le routage au nœud climatisation coûte 0,40 * 100 * 2 euros soient quatre-vingt euros.
La connaissance des coût relatifs des pilotes suivant le nombre d'exemplaire permet d'affiner l'estimation économique. Si pour une série de 40 000 exemplaires, un pilote de type PWM (Puise Width Modulation) coûte 1 euro, mais 0,5 euros pour une série de 100 000 exemplaires, alors pour une série de 100.000 exemplaires et un taux de monte de la climatisation à 40%, le coût du pilote sur le calculateur de climatisation sera de 1 euro alors que le coût de ce pilote sur le calculateur UCH sera de 0,5 euros et l'équation économique devient 100 + 100*0,5 euros soient 150 euros pour l'UCH et 80 + 0,4*100*1 euro soit 120 euros pour le scénario du routage sur un calculateur de clim. Il est donc toujours intéressant de choisir le scénario "calculateur de climatisation".
Si maintenant on estime un coût de montage, calculé en fonction
- d'un coût de montage d'un toron nécessaire à la mise en œuvre de la climatisation sur la zone cockpit par exemple, - d'un coût de montage d'un connecteur nécessaire à la mise en œuvre de la climatisation sur une frontière de la zone cockpit ou sur la zone cockpit,
- d'un coût de montage du calculateur de climatisation et/ou habitacle sur la zone cockpit ou une autre zone spécifiée par le concepteur,
- d'un coût de montage des capteurs ou des actionneurs nécessaire à la mise en œuvre de la climatisation sur une zone et
- d'un coût de connexion des différents connecteurs actionneurs nécessaires à la mise en œuvre de la climatisation entre zones ou dans une zone.
Alors, étant donnée une évaluation pour le calculateur de climatisation qui est optionnel de 1 euro; et de 2 euros pour le calculateur habitacle, pour un taux de monte à 40% de la prestation climatisation, l'option du routage sur calculateur de climatisation revient à 120 euros + 0,4*100*1 + 1*100*2 soient 360 euros, alors que le coût du routage sur le calculateur habitacle est de 150 euros + 1*100*2 soient 350 euros.
Tout d'un coup le calculateur de climatisation n'est plus justifié. Affinons encore notre analyse. Prenons un impact qualité de 100 ppm (panne par million) sur 3 ans, un période de garantie type, à la fois pour le calculateur climatisation et le calculateur habitacle. Estimons d'autre part à 200 euros le coût moyen d'un remplacement de calculateur et affectons un coût de montage/démontage de 50 euros pour la zone dans laquelle se trouve le calculateur de climatisation et de 10 euros pour la zone dans laquelle on a placé le calculateur habitacle. Supposons par ailleurs que les défauts qualité associés aux câblages dans les deux scénarios soient identiques et de 100 ppm mais de coût de réparation négligeable sauf pour le démontage. Pour simplifier on suppose que la majorité du câblage considéré se trouve dans une zone à 50 euros comme le calculateur de climatisation. Alors, le coût unitaire pour le remplacement de calculateur est de 100*200/ 1 000 000 soit 0,04 euros à majorer de 0,01 euro pour le calculateur de climatisation et de 0,002 euros pour le calculateur de climatisation. Le coût de réparation du câblage est luis de 0,01 euro pour un défaut sur l'ensemble du câblage qui n'est présent que lorsque l'option climatisation est retenue. Notre coût unitaire consolidé intégrant les défauts qualité est donc maintenant de 360 + 0,4 * 100 * ((0,04 + 0,01)(calculateur) + 0,01 (câblage)) euros soient 362,4 euros alors que le scénario avec calculateur habitacle coûte maintenant 350 + 0,4*100*0,01 soit 350,4 euros si l'on tient compte du fait que les coûts qualité liés au calculateur habitacle sont présents à l'identique dans les deux scénarios et que le câblage spécifique à la climatisation n'est monté que lorsque l'option climatisation est retenue. Notons au passage que le nombre de ppm du scénario avec calculateur de climatisation est de 0,4*(100 + 100) soit 80 ppm alors que le nombre de ppm du scénario sans calculateur de climatisation est de 0,4*100 soit 40 ppm si l'on fait abstraction des ppm liés au calculateur habitacle constant dans les deux scénarios. Sur le plan qualité, le scénario sans calculateur de climatisation est donc préférable.
Si l'on prend maintenant l'impact poids en compte et que l'on estime à 1 euro le coût consolidé d'une charge d'un kilo. Etant donné d'une part un poids de 300 grammes pour le calculateur climatisation et de 100 grammes pour le routage des actionneurs spécifiques de la climatisation au calculateur climatisation et d'autre part un surpoids de 150 grammes du calculateur habitacle et de 150 grammes pour le routage des actionneurs spécifiques de la climatisation au calculateur habitacle, on trouve maintenant que le coût du scénario avec calculateur de climatisation toujours pour cent exemplaires est de 362,4 + 0,4*100*0,4(400 grammes)* 1(coût au kilo) euro soient 378,4 euros et de 350,4 + 0,4*100 * 0,3 (300 grammes)* 1 + 0,6*100*0,150*1 euro soient 363,3 euros pour le scénario avec calculateur habitacle. Au passage, on a vu que l'hypothèse avec calculateur de climatisation entraînait un surpoids de 400 grammes alors que cette du placement de la climatisation sur le calculateur habitacle pèse 300 grammes lorsque la climatisation est installée. En moyenne pondérée, le poids du scénario avec calculateur de climatisation est 0,4(taux de monte)*0,4(kilos) soit 160 grammes alors que le poids de l'option sans calculateur de climatisation est 0,4 (taux de monte clim) * 0,3(300 grammes) + 0,6(sans clim)*0,150(poids du surplus calculateur) soit un poids marginal de 129 grammes et c'est ce dernier câblage qui est optimal en poids.
Pour conclure, il faut encore prendre en compte le coût de l'exécution des opérations élémentaires de la prestation climatisation dans chacun des scénarios, coût qui doit être consolidé dans le coût pièce des calculateurs. Supposons que les opérations élémentaires de la climatisation nécessitent 1 MIPS et que le coût marginal du MIPS dans un processeur soit renseigné dans un abaque et donne pour 1 MIPS 2 euros et pour 20
MIPS 10 euros et 9,6 euros pour 19 MIPS. Supposons d'autre part que indépendamment de la prestation climatisation, le calculateur habitacle embarque 19 MIPS d'exécution d'opérations élémentaires. Finalement, prenons l'hypothèse d'un coût linéaire de la RAM à,
1 euros pour 2 kilos octets et d'un coût linéaire de la flash à 4 euros pour un Mega-octet.
Finalement les opérations élémentaires de la prestation climatisation nécessitent 2 k de
RAM et 100 k de Flash. Dans ce cas le bilan consolidé pour 100 véhicules pour les deux scénarios devient:
378,4 + 0,4*100*(2+1 +0,1*4) euros soient 514,4 euros pour le scénario avec un calculateur de climatisation alors que dans le cas où le code est exécuté entièrement sur le calculateur habitacle, le coût devient: 363,3 + 1*100*((10-9,6) +1 + 0,1*4) euros soient 543,3 euros.
Au final le coût consolidé unitaire de la solution avec calculateur de climatisation est donc de 5,14 euros alors que le coût de la solution sans calculateur de climatisation est de 5,43 euros par unité avec l'hypothèse d'une série de 100 000 véhicules et un taux de monte de la climatisation de 40%.
L'outil de conception d'architecture de système décrit ci-dessus permet de réaliser une pluralité de validations tout au long du processus de conception. On distingue - la validation fonctionnelle qui consiste à vérifier que toute donnée consommée par une opération élémentaire doit être produite par une opération élémentaire indépendamment du lien des opérations élémentaires aux différentes prestations. Cette étape peut être menée une fois l'architecture fonctionnelle renseignée dans les fenêtres REQ et FUNC accessibles par les onglets 611 et 612.
La validation fonctionnelle après placement qui consiste à vérifier que toute donnée consommée par une opération élémentaire doit être produite par une opération élémentaire et de plus, qu'entre le producteur et le consommateur, il existe un chemin constitué éventuellement de réseaux et de nœuds intermédiaires. Cette étape peut être menée une fois le placement des prestations réalisé complètement ou partiellement dans la fenêtre MAP accessible par l'onglet 613.
La validation fonctionnelle et de messagerie qui consiste à vérifier que toute donnée consommée par une opération élémentaire doit être produite par une opération élémentaire et que de plus, entre le producteur et le consommateur, il existe un chemin constitué éventuellement de réseaux et de nœuds intermédiaires et de plus, pour au moins un chemin, des emplacements dans des trames sont provisionnés pour l'acheminement de la donnée du producteur au consommateur. Cette étape peut être réalisée lorsque les trames de données ont été partiellement ou complètement réalisées à l'aide des fenêtres
HWD et MSG accessibles par les onglets 615 et 616. - La validation de l'architecture des prestations par configuration et/ou par mode qui consiste à appliquer les trois validations précédentes d'une part pour chaque configuration du produit et d'autre part pour chaque mode transversal du produit.
Par exemple pour une configuration dont les seules options et choix de calculateur sont climatisation présente ou pas et contrôle essence ou diesel, on doit donc appliquer les validations aux quatre variantes résultantes : essence avec ou sans climatisation et diesel avec ou sans climatisation. Pour ce qui est de la validation pour un mode donnée, la configuration étant fixée, on peut reproduire chaque type de validation mais que pour le sous-ensemble des opération élémentaires qui sont potentiellement actives lorsque le moteur est arrêté.
Ces validations sont accessibles par un menu utilisateur (non représenté) accessible en cliquant sur l'onglet Tools 606 représenté notamment en Figure 6. Dans ce menu utilisateur, on peut choisir d'une part l'une des trois validations, validation fonctionnelle, validation fonctionnelle après placement et validation fonctionnelle et de messagerie, et d'autre le périmètre à retenir pour ces validations, le sous ensemble de variantes de calculateur et/ou de variantes de prestation, le mode ou l'ensemble de mode, et/ou la configuration ou l'ensemble de configuration sur lesquels ces validations doivent être réalisées.
Toutes ces validations sont réalisées automatiquement à partir des données spécifiées dans l'outil de conception d'architecture de système
Etant donné un cas d'utilisation, on exprime une contrainte de performance sur ce cas d'utilisation ainsi que sur certaines des opérations élémentaires réalisées dans l'état d'arrivée dudit cas d'utilisation, et on valide que cette contrainte de performance est satisfaite pour un placement des différentes opérations élémentaires.
A titre d'exemple, prenons le cas d'utilisation que nous appellerons CRASH: "Dans un contexte moteur tournant, si un crash est détecté, alors le véhicule doit se déverrouiller d'urgence". Pour implementer ce cas, une requête "crash détecté" est spécifiée. Elle est réalisé par une opération élémentaire qui capture la valeur donnée par un accéléromètre "A". Cette valeur est "a". Le pilote logiciel de capture de l'accélération correspond au programme "P1 ". Dans ce cas, l'état d'arrivé du cas d'utilisation CRASH est par exemple un état que nous nommerons "Déverrouillage d'urgence". Dans cet état, l'opération élémentaire "déverrouillage des portes" est réalisée. Elle correspond à une donnée d mise à 1 qui commande par un pilote logiciel P2 qui commande les verrous des portes Vi. Si l'on donne une contrainte de performance de 100ms sur la réalisation du cas d'utilisation CRASH cela signifie:
Que l'accéléromètre a détecté une valeur de crash a. - que la valeur de a a été rafraîchie en exécutant le pilote P1 que l'entrée dans l'état Déverrouillage d'urgence a été réalisée que la donnée d a été mise à 1 que le logiciel P2 a été exécuté que les verrous Vi ont fonctionné le tout en moins de 100 ms. Certaines de ces étapes étant parallèles et d'autres séquentielles.
Si maintenant, de plus, l'accéléromètre est placé sur un calculateur d'airbag et la commande des verrous est placée sur un autre calculateur, par exemple le calculateur habitacle, et ces deux calculateurs sont reliés par un bus CAN sur lequel la donnée a est transportée par une trame T. Alors la contrainte de 100 ms signifie maintenant:
Que l'accéléromètre a détecté une valeur de crash a. que la valeur de a a été rafraîchie en exécutant le pilote P1 que la valeur de a a été écrite dans le pilote CAN du calculateur Airbag pour rémission de la trame T - que la trame T a circulé sur le bus que la trame T a été lue et la valeur de a extraite par le pilote CAN du calculateur habitacle que l'entrée dans l'état Déverrouillage d'urgence a été réalisée que la donnée d a été mise à 1 - que le logiciel P2 a été exécuté que les verrous Vi ont fonctionné le tout en moins de 100ms. On à partir de cette liste établir des exigences de performance pour l'exécution de chacune de ces étapes. Par exemple, on peut proposer que la trame T soit émise toute les 20ms ce qui laisse 80ms de temps d'exécution pour les autres opérations qui sont séquentiellement exécutées avant ou après l'émission de la trame. Si cette hypothèse s'avère trop difficile à tenir, on réduira le temps de transmission de T à 10ms par exemple. Si au contraire, on s'aperçoit que le réseau par lequel T transite est très chargé, on tentera d'émettre une exigence d'émission toutes les 30ms pour T et l'on tentera de réaliser toutes les opérations qui doivent se dérouler avant ou après l'émission de T en moins de 70ms. Réciproquement, si des exigences de performance ont été exprimées sur ces divers opérations, on peut vérifier que la somme de ces opérations se fait bien en moins de 100ms. Finalement, si certaines exigences sont spécifiées mais pas d'autre, on déduit des exigences déjà spécifiées le temps restant pour exécuter toutes les opérations sur lesquelles aucune contrainte n'est exprimée. Si l'on recherche une anomalie liée à la réalisation du cas d'utilisation CRASH cela signifie que l'on peut rechercher en priorité les causes parmi les différentes composantes réalisant le cas d'utilisation CRASH, telles que:: l'accéléromètre a détecté une valeur de crash a. la valeur de a a été rafraîchie en exécutant le pilote P1 - l'entrée dans l'état Déverrouillage d'urgence a été réalisée la donnée d a été mise à 1 le logiciel P2 a été exécuté les verrous Vi ont fonctionné On peut ainsi synthétiser automatiquement la liste des opérations élémentaires, exécutions de pilotes, écritures et lectures dans des trames, prise en compte d'information par des capteur et des actionneurs, transfert de trame sur un réseau, notamment, décrire toutes les opérations à effectuer lors de la réalisation d'un cas d'utilisation afin de savoir exactement dans quel ensemble d'objets rechercher la cause d'un défaut détectée lors de l'exécution du cas d'utilisation CRASH. Une fois le placement réalisé, on peut identifier automatiquement dans chaque mode transversal t les opérations élémentaires qui doivent être opérationnelles. Lorsqu'au moins une opération élémentaire fonctionne sur un calculateur, cela signifie qu'une initialisation même partielle du calculateur doit être effectuée dans le mode correspondant. Lorsque aucune opération élémentaire ne s'exécute dans un mode transversal donné sur un calculateur, cela signifie qu'il peut être désactivé.
A la différence du brevet EP-0696775A1 , dans la présente invention une topologie 2-D n'est pas un pré-requis. Une topologie 2-D est un résultat du procédé de la présente invention et par conséquence peut être utilisé par exemple comme une entrée de tels systèmes. Aussi, selon la présente invention, les chemins sont générés automatiquement.
On observe que le procédé de conception et l'outil correspondant permettent des démarches
"top-down", en suivant les onglets, dans l'ordre, comme exposé dans la description, et "bottom-up", c'est-à-dire en suivant tout ordre de spécification voulu par le concepteur, y compris en sélectionnant les onglets dans l'ordre inverse de ce qui est exposé dans la description.
Il sera aussi apprécié que la procédure de la présent invention peut être réalisée dans la forme d'un programme d'ordinateur et enregistrée sur la mémoire d'un ordinateur. Des articles manufacturés pourront être produit sur lesquels de tels programmes d'ordinateur pourront être enregistrés.

Claims

REVENDICATIONS
1. Procédé de conception d'une spécification d'un système matériel et logiciel, caractérisé en ce qu'il comporte : - une étape de définition de prestations et, pour chaque prestation, de cas d'utilisation ;
- une étape d'association de chaque cas d'utilisation à au moins un état de départ du système, une demande utilisateur et, pour chaque état de départ, un état d'arrivée du système ; - une étape de définition d'opérations au cours de laquelle, pour chaque état, on définit un ensemble d'opérations élémentaires correspondant à la réponse du système lors de l'arrivée dans ledit état ;
- une étape de spécification d'architecture du système définissant des unités de contrôle électronique et des réseaux ; - une étape de placement des opérations élémentaires sur les calculateurs ; et, au moins l'une des étapes suivantes :
- une étape d'identification des flots de données circulant sur lesdits réseaux en fonction dudit placement ; et
- une étape d'identification de la spécification des interfaces des calculateurs en fonction dudit placement.
2. Procédé selon la revendication 1 caractérisé en ce que l'étape de placement comporte, pour chaque prestation, un choix parmi plusieurs modes de placement comportant notamment : - le placement de la prestation sur un seul calculateur,
- le placement maître - esclave dans lequel une opération élémentaire supplémentaire de contrôle de la prestation unique, active, suivant l'état de la prestation dans lequel se trouve le système, les opérations élémentaires de la prestation, cette opération élémentaire supplémentaire étant placée sur l'un des calculateurs, - le placement distribuée dans lequel les opérations élémentaires sont réparties sur au moins deux calculateurs et, sur chacun desdits calculateurs, une opération élémentaire supplémentaire de contrôle de la prestation est placée et active, suivant l'état de la prestation dans lequel se trouve le système, les opérations élémentaires de la prestation placées sur ledit calculateur.
3. Procédé selon la revendication 2 caractérisé en ce que, les opérations élémentaires supplémentaires sont générées automatiquement avec : - comme entrées, toutes les données nécessaires au calcul des transitions de l'automate de contrôle de la prestation dont les états sont les états de la prestation et les transitions les traductions, par une opération élémentaire, des demandes utilisateur et
- comme sortie, une donnée représentant l'état dans lequel se trouve la prestation.
4. Procédé selon l'une des revendications précédentes caractérisé en ce que, au cours de l'étape d'identification des flots de données, on détermine un état de chaque flot de données, par rapport à une messagerie donnée :
- données libres à placer dans des trames, - données déjà placées dans une trame et circulant sur le réseau et telles qu'elles sont produites dans les calculateurs où la trame est produite et consommée dans les calculateurs où la trame est consommée, et
- emplacements de trame non utilisés.
5. Procédé selon l'une des revendications précédentes caractérisé en ce que, étant donné un cas d'utilisation,
- on exprime une contrainte de performance sur ce cas d'utilisation ainsi que sur certaines des opérations élémentaires réalisées dans l'état d'arrivée dudit cas d'utilisation, - on synthétise alors automatiquement la liste des exécutions d'opérations élémentaires, exécutions de pilotes, écritures et lectures dans des trames, prise en compte d'information par des capteur et des actionneurs, transfert de trame sur un réseau mise en œuvres suite au placement desdites opérations élémentaires ,
- on spécifie des exigences de délai d'exécution et/ou de temps de réponse de transmission, de lecture et d'écriture des trames, d'exécution des pilotes et des opérations élémentaires,
- on indique les temps de réponse des capteurs et des actionneurs
- on valide que cette contrainte de performance est satisfaite pour un placement desdites opérations élémentaires ou spécifier des exigences de délai d'exécution et/ou de temps de réponse pour satisfaire cette contrainte de performance.
6. Procédé selon l'une des revendications précédentes caractérisé en ce que si, pour une prestation possédant au moins deux variantes, lesdites variantes ont des opérations élémentaires partagées, alors lesdites opérations élémentaires sont placées automatiquement sur les mêmes calculateurs ou variantes de calculateur lorsque le placement d'une des variantes est réalisé. Par exemple des variantes d'accès au véhicule, l'une avec clé, l'autre sans clé, partagerons les opérations élémentaires de verrouillage et déverrouillage.
7. Dispositif de conception d'une spécification d'un système matériel et logiciel, comportant :
- un moyen de définition de prestations et, pour chaque prestation, de cas d'utilisation ;
- un moyen d'association de chaque cas d'utilisation à au moins un état de départ du système, une demande utilisateur et, pour chaque état de départ, un état d'arrivée du système ;
- un moyen de définition d'opérations au cours de laquelle, pour chaque état, on définit un ensemble d'opérations élémentaires correspondant à la réponse du système lors de l'arrivée dans ledit état ;
- un moyen de spécification d'architecture du système définissant des unités de contrôle électronique et des réseaux ;
- un moyen de placement des opérations élémentaires sur les calculateurs ; et, au moins l'un des moyens suivants :
- un moyen d'identification des flots de données circulant sur lesdits réseaux en fonction dudit placement ; et - un moyen d'identification de la spécification des interfaces des calculateurs en fonction dudit placement.
8. Dispositif selon la revendication 7 caractérisé en ce que, le dispositif comporte un moyen de sélection, de préférence un onglet, d'une description hiérarchisée, la sélection de chaque moyen de sélection faisant apparaître un écran différent du dispositif.
9. Dispositif selon l'une des revendications précédentes caractérisé en ce que, pour au moins un écran, la description hiérarchisée représente, à un premier niveau de hiérarchie, une pluralité de prestations, et à un deuxième niveau de hiérarchie, une pluralité de cas d'utilisation pour chaque prestation, par exemple une prestation "essuie-glaces" peut être définie par des cas d'utilisation de balayage alterné, de balayage lent et de balayage rapide.
10. Dispositif selon la revendication 9 caractérisé en ce que, pour au moins un dit écran, chaque cas d'utilisation comporte un contexte ou situation initiale du système, une demande d'un utilisateur au système et une réponse du système correspondant à un changement de son état.
11. Dispositif selon les revendications 9 et 10 caractérisé en ce que, dans au moins un écran, pour chaque cas d'utilisation d'une prestation, des états et des transitions d'état associées sont définis.
12. Dispositif selon l'une des revendications 7 à 11 caractérisé en ce que, les états qui fonctionnent dans des modes transverses aux prestations communs sont regroupés, dans des phases, chaque état est associé à une phase du système, l'ensemble des cas d'utilisation formalisés représentant toutes les réponses ou absences de réponse du système dans toutes les phases, celles ci représentant, ensemble, toutes les combinaisons des modes de fonctionnement du véhicule.
13. Dispositif selon la revendication 12 caractérisé en ce que, chaque phase est constituée d'un ensemble de combinaisons des modes de fonctionnement du véhicule, les modes étant transversaux aux prestations et hors du contrôle direct des prestations, par exemple un mode représentant un niveau d'énergie disponible et/ou un type d'utilisateur du système et ou un état accidenté ou non d'un véhicule.
14. Dispositif selon l'une des revendications précédentes caractérisé en ce que, pour au moins un écran, la description hiérarchisée représente, à un premier niveau de hiérarchie, une pluralité de prestations, et à un deuxième niveau de hiérarchie, des phases de la prestation.
15 - Dispositif selon l'une quelconque des revendications 10 à 14, caractérisé en ce que, pour au moins un écran, la description hiérarchisée représente, à un premier niveau de hiérarchie, une pluralité de prestations, et à un deuxième niveau de hiérarchie, des états.
16 - Dispositif selon l'une quelconque des revendications 14 ou 15, caractérisé en ce que, dans la description hiérarchisée, un niveau hiérarchique décrit, dans un état donné, les opérations élémentaires.
17 - Dispositif selon l'une quelconque des revendications 7 à 16, caractérisé en ce que, pour au moins un écran, un placement d'opérations élémentaires sur des composants représentés sur une vue synthétique peut être effectué.
18 - Dispositif selon la revendication 17, caractérisé en ce qu'il comporte, pour au moins un écran, une vue synthétique représentant une enveloppe d'un composant et chaque opération élémentaire que ledit composant contrôle ou commande.
19 - Dispositif selon l'une quelconque des revendications 7 à 18, caractérisé en ce qu'il comporte, pour au moins un écran, une vue synthétique représentant une enveloppe d'une prestation et chaque opération élémentaire que ladite prestation comporte.
20 - Dispositif selon l'une quelconque des revendications 7 à 19, caractérisé en ce que, pour au moins un écran, la description hiérarchisée représente des calculateurs du système, à un premier niveau de hiérarchie, et à un deuxième niveau de hiérarchie, des opérations élémentaires contrôlées ou commandées électroniquement par chaque calculateur.
21 - Dispositif selon la revendication 20, caractérisé en ce que, pour chaque dit écran, un niveau hiérarchique représente, pour chaque calculateur, les prestations qui sont, au moins partiellement, placées sur ledit calculateur.
22 - Dispositif selon l'une quelconque des revendications 20 ou 21 , caractérisé en ce que, pour chaque dit écran, une vue synthétique représente, pour chaque calculateur, les modes dans lesquels ledit calculateur doit fonctionner.
23 - Dispositif selon l'une quelconque des revendications 7 à 22, caractérisé en ce que, pour au moins un écran, une vue synthétique représente au moins un réseau et les composants qui y sont reliés.
24 - Dispositif selon l'une quelconque des revendications 7 à 23, caractérisé en ce que, pour au moins un écran, la description hiérarchisée représente des calculateurs du système, à un premier niveau de hiérarchie, et à un deuxième niveau de hiérarchie, pour chaque calculateur, les trames de données transitant sur les bus auxquels est connecté le calculateur et/ou les composants électroniques (capteurs, actionneurs) directement connectés au calculateur.
25 - Dispositif selon l'une quelconque des revendications 7 à 24, caractérisé en ce que, pour au moins un écran, la description hiérarchisée représente des trames, à un premier niveau de hiérarchie, et à un deuxième niveau de hiérarchie, pour chaque trame, les données contenues dans les trames.
26 - Dispositif selon l'une quelconque des revendications 7 à 25, caractérisé en ce que, pour au moins un écran, une vue synthétique représente des composants et/ou réseaux et une projection d'une prestation sur lesdits composants et/ou réseaux.
27 - Dispositif selon l'une quelconque des revendications 7 à 26, pour au moins un écran, un niveau hiérarchique décrit, pour chaque opération élémentaire, les flots de données d'entrée et de sortie d'interface, pour chaque flot de données, le pilote et le composant et/ou l'opération élémentaire, avec lequel le flot de données est échangé.
28 - Dispositif selon l'une quelconque des revendications 7 à 27, caractérisé en ce que, pour au moins un écran, la description hiérarchisée représente, à un premier niveau de hiérarchie, une pluralité de prestations, et à un deuxième niveau de hiérarchie, une pluralité de variantes de prestation, pour chaque prestation.
29 - Dispositif selon l'une quelconque des revendications 7 à 28, caractérisé en ce que, pour au moins un écran, la description hiérarchisée représente, à un premier niveau de hiérarchie, une pluralité de composants électroniques, et à un deuxième niveau de hiérarchie, une pluralité de variantes de composants électroniques, pour chaque composant électronique.
30 - Dispositif selon l'une quelconque des revendications 7 à 29, caractérisé en ce que, pour au moins une vue synthétique, une sélection, avec un dispositif de pointage, d'un élément de la vue synthétique donne accès à une représentation de fonctionnement dudit élément.
31. Dispositif selon l'une quelconque des revendications 7 à 30, caractérisé en ce que, pour un cas d'utilisation, étant donné un placement partiel ou complet des prestations, on identifie automatiquement l'ensemble des opérations élémentaires dans l'architecture ainsi que l'ensemble des données échangées (trames, capteurs, actionneurs) correspondant à la réalisation du cas d'utilisation.
32. Dispositif selon l'une quelconque des revendications 7 à 31, caractérisé en ce que, pour un cas d'utilisation, si on exprime une contrainte de performance sur ledit cas d'utilisation, on identifie automatiquement l'ensemble des opérations élémentaires dans l'architecture, l'ensemble des trames échangées, l'ensemble des capteurs nécessaires et/ou l'ensemble des actionneurs activés, de manière à leur affecter respectivement des contraintes de délai d'exécution, de délai de transmission, de délai d'activation propres et/ou valider des contraintes déjà exprimées.
33. Dispositif selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comporte, pour des objets, composants matériels et/ou prestations offertes au client, une représentation graphique dite "enveloppe" qui comporte :
- un contour représentant ledit objet,
- des représentations d'autres objets avec lequel ledit objet communique, et
- des représentations de données échangées avec lesdits autres objets.
34. Dispositif selon la revendication 32, caractérisé en ce que, lorsque ladite enveloppe représente un composant matériels, les représentations de données sont effectuées pour une prestation.
35. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte, pour chaque bus, une représentation des composants qui y sont directement reliés et, pour les composants directement reliés à au moins deux bus, pour chacun de ces bus, associé audit composant, un identificateur de chaque autre bus auquel ledit composant est directement relié.
36. Dispositif selon la revendication 35, caractérisé en ce que ledit identificateur est un élément graphique, par exemple une pastille d'une couleur identique à celle du bus dans ladite représentation.
37. Article manufacturé comprenant un moyen de stockage d'ordinateur ayant un programme d'ordinateur pour la conception d'une spécification d'un système matériel et logiciel caractérisé en ce que le programme comprend un code pour réaliser les étapes de la procédure définie dans l'une des revendications 1 à 6.
PCT/FR2003/003108 2002-10-21 2003-10-21 Procede et dispositif pour synthetiser une architecture electrique WO2004038618A2 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
AU2003285418A AU2003285418A1 (en) 2002-10-21 2003-10-21 Method and device for synthesising an electrical architecture
US10/532,089 US20060229742A1 (en) 2002-10-21 2003-10-21 Method and device for synthesising an electrical architecture
JP2004546103A JP2006504170A (ja) 2002-10-21 2003-10-21 電気アーキテクチャ合成方法及び合成装置
EP03778417A EP1556803A2 (fr) 2002-10-21 2003-10-21 Procede et dispositif pour synthetiser une architecture electrique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR02/13112 2002-10-21
FR0213112A FR2846117B1 (fr) 2002-10-21 2002-10-21 Procede et dispositif pour synthetiser une architecture electrique

Publications (2)

Publication Number Publication Date
WO2004038618A2 true WO2004038618A2 (fr) 2004-05-06
WO2004038618A3 WO2004038618A3 (fr) 2004-07-01

Family

ID=32050602

Family Applications (3)

Application Number Title Priority Date Filing Date
PCT/FR2003/003107 WO2004038617A2 (fr) 2002-10-21 2003-10-21 Procede et dispositif pour synthetiser une architecture electrique
PCT/FR2003/003108 WO2004038618A2 (fr) 2002-10-21 2003-10-21 Procede et dispositif pour synthetiser une architecture electrique
PCT/FR2003/003109 WO2004038619A2 (fr) 2002-10-21 2003-10-21 Procede et dispositif pour synthetiser une archotecture electrique

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/003107 WO2004038617A2 (fr) 2002-10-21 2003-10-21 Procede et dispositif pour synthetiser une architecture electrique

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/003109 WO2004038619A2 (fr) 2002-10-21 2003-10-21 Procede et dispositif pour synthetiser une archotecture electrique

Country Status (7)

Country Link
US (3) US7441225B2 (fr)
EP (3) EP1556804A2 (fr)
JP (3) JP2006504171A (fr)
KR (3) KR101004302B1 (fr)
AU (3) AU2003289672A1 (fr)
FR (1) FR2846117B1 (fr)
WO (3) WO2004038617A2 (fr)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE511669T1 (de) * 2004-01-13 2011-06-15 Renault Sas Entwurf von sicherheitskritischen systemen
US7346478B2 (en) * 2004-09-21 2008-03-18 Ford Motor Company Method of embedding tooling control data within mechanical fixture design to enable programmable logic control verification simulation
US7912740B2 (en) * 2004-11-01 2011-03-22 Claims Services Group, Inc. System and method for processing work products for vehicles via the world wide web
US20060242089A1 (en) 2005-04-26 2006-10-26 Shahram Vahidi Web based repair cost estimating system
US7376926B1 (en) * 2005-04-29 2008-05-20 Xilinx, Inc. Run-time efficient methods for routing large multi-fanout nets
US7929461B2 (en) * 2005-06-09 2011-04-19 Tekronix, Inc. Controller area network performance parameters measurement
US7302662B2 (en) * 2006-03-28 2007-11-27 National Tsing Hua University Method for post-routing redundant via insertion in integrated circuit layout
US8300798B1 (en) 2006-04-03 2012-10-30 Wai Wu Intelligent communication routing system and method
US8146052B2 (en) * 2006-08-22 2012-03-27 Caterpillar Inc. Method and system for hierarchical hardware mapping for software design
US7937169B2 (en) * 2006-08-25 2011-05-03 The Boeing Company System and method for compartment control
US9201854B1 (en) * 2006-10-25 2015-12-01 Hewlett-Packard Development Company, L.P. Methods and systems for creating, interacting with, and utilizing a superactive document
US9330230B2 (en) * 2007-04-19 2016-05-03 International Business Machines Corporation Validating a cabling topology in a distributed computing system
JP2009211351A (ja) * 2008-03-04 2009-09-17 Mazda Motor Corp 車両用制御ユニット設計支援装置及び方法
US20100199185A1 (en) * 2009-02-04 2010-08-05 Microsoft Corporation Common navigation mechanism for desktop and browser-based applications
US8898618B2 (en) * 2009-03-26 2014-11-25 Altera Corporation Interactive simplification of schematic diagram of integrated circuit design
US8484366B2 (en) * 2010-01-05 2013-07-09 Accenture Global Services Limited Hierarchical service management
TWI465951B (zh) * 2010-03-23 2014-12-21 Hon Hai Prec Ind Co Ltd 過流保護電路設計系統和方法
FR2963133B1 (fr) 2010-07-23 2012-08-10 Eurocopter France Procede et dispositif pour synthetiser une architecture electrique et electronique.
US8880381B2 (en) * 2010-10-01 2014-11-04 The Boeing Company Optimization of processor characteristics and large scale system optimization through domain decomposition
SE535962C2 (sv) * 2011-06-23 2013-03-05 Zoliex Ab Ett styrförfarande i ett nätverk
FR2978265A1 (fr) 2011-07-20 2013-01-25 Eads Europ Aeronautic Defence Procede automatique base sur des modeles pour la generation d'architectures physiques de systemes et leur optimisation
US9378562B1 (en) * 2012-12-21 2016-06-28 The Mathworks, Inc. Management of variants in a graphical modeling environment
US10078714B2 (en) * 2013-10-31 2018-09-18 Cadence Design Systems, Inc. Data propagation analysis for debugging a circuit design
JP5967265B2 (ja) * 2014-07-31 2016-08-10 ダイキン工業株式会社 機器制御装置
US10281507B2 (en) 2014-11-21 2019-05-07 Kohler Co. Generator sizing
USD810104S1 (en) 2015-11-16 2018-02-13 Kohler, Co. Display screen with graphical user interface
USD811423S1 (en) 2015-11-16 2018-02-27 Kohler, Co. Display screen with graphical user interface
US10496048B2 (en) * 2016-11-02 2019-12-03 Edison Labs, Inc. Switch terminal methods with wiring components secured to circuitry wiring without external live points of contact
US10642231B1 (en) * 2016-11-02 2020-05-05 Edison Labs, Inc. Switch terminal system with an activity assistant
US10521197B1 (en) 2016-12-02 2019-12-31 The Mathworks, Inc. Variant modeling elements in graphical programs
US10661764B1 (en) * 2017-03-28 2020-05-26 Apple Inc. Braking system control state transitions
US20180373818A1 (en) * 2017-06-22 2018-12-27 GM Global Technology Operations LLC Systems and methods for reconfiguration of electrical architecture for automotive design options
US11829689B1 (en) 2020-06-09 2023-11-28 The Mathworks, Inc. Systems and methods for creating variant regions in acausal simulation models
CN112803304A (zh) * 2021-03-03 2021-05-14 中国电力工程顾问集团中南电力设计院有限公司 电缆敷设方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0696775A1 (fr) 1993-04-21 1996-02-14 Hitachi, Ltd. Système de conception et de production assisté par ordinateur pour la disposition d'éléments et l'interconnexion de tuyaux

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06195402A (ja) * 1992-10-26 1994-07-15 Hitachi Ltd 製品開発最適設計支援システム
US5452218A (en) * 1994-02-03 1995-09-19 Texas Instruments System and method for determining quality analysis on fabrication and/or assembly design using shop capability data
JPH07320081A (ja) * 1994-05-23 1995-12-08 Fujitsu Ltd 図形編集装置及び方法
US5648898A (en) * 1994-12-19 1997-07-15 Caterpillar Inc. Method for programming a vehicle monitoring and control system
US5870588A (en) * 1995-10-23 1999-02-09 Interuniversitair Micro-Elektronica Centrum(Imec Vzw) Design environment and a design method for hardware/software co-design
US5793648A (en) * 1996-09-30 1998-08-11 Freightliner Corporation Method and system for automating control panel layout and wiring specifications for a vehicle manufacturing process
US6106298A (en) * 1996-10-28 2000-08-22 Lockheed Martin Corporation Reconfigurable easily deployable simulator
US5880957A (en) * 1996-12-03 1999-03-09 Caterpillar Inc. Method for programming hydraulic implement control system
FR2775806B1 (fr) * 1998-03-04 2001-11-23 Valeo Electronique Outil informatique pour l'etude d'architectures electriques destinees a etre disposees a l'interieur d'un vehicule automobile
JP2000020291A (ja) * 1998-07-06 2000-01-21 Toyota Motor Corp 車両用プログラム開発支援方法および装置
DE19838333A1 (de) * 1998-08-24 2000-03-02 Bosch Gmbh Robert System zur Steuerung des Antriebs eines Fahrzeugs
US6571191B1 (en) * 1998-10-27 2003-05-27 Cummins, Inc. Method and system for recalibration of an electronic control module
US6272387B1 (en) * 1998-11-06 2001-08-07 The Boeing Company Wire harness system
JP3732664B2 (ja) * 1998-11-30 2006-01-05 矢崎総業株式会社 ワイヤーハーネス配索設計装置及びその方法
US6276477B1 (en) * 1999-01-27 2001-08-21 Ida Automotive Component car system
US6606731B1 (en) * 1999-08-05 2003-08-12 The Boeing Company Intelligent wiring diagram system
JP2001257268A (ja) * 2000-03-13 2001-09-21 Nec Microsystems Ltd レイアウト方法
US6516451B1 (en) * 2000-07-05 2003-02-04 Clarence Wayne Patin Standards-integrated design software
US6785805B1 (en) * 2000-08-08 2004-08-31 Vi Technology, Inc. Network-based configuration method for systems integration in test, measurement, and automation environments
US6442451B1 (en) * 2000-12-28 2002-08-27 Robotic Workspace Technologies, Inc. Versatile robot control system
US7107197B1 (en) * 2001-01-26 2006-09-12 Mentor Graphics Corporation Wiring harness data systems
JP3761155B2 (ja) * 2001-03-26 2006-03-29 富士通テン株式会社 データ演算装置およびそれを用いる電子制御機器の調整方法
FR2824213B1 (fr) 2001-04-27 2003-08-01 Renault Dispositif de generation d'une messagerie commune a plusieurs systemes electroniques produisant et consommant des donnees
JP2003022721A (ja) * 2001-07-09 2003-01-24 Sumitomo Wiring Syst Ltd ワイヤーハーネス設計支援方法及びプログラム
US6968918B2 (en) * 2001-08-23 2005-11-29 General Motors Corporation Vehicle chassis having programmable operating characteristics and method for using same
JP3956693B2 (ja) * 2001-12-27 2007-08-08 トヨタ自動車株式会社 統合型車両運動制御装置
US7437688B2 (en) * 2001-12-27 2008-10-14 Caterpillar Inc. Element routing method and apparatus
US6785595B2 (en) * 2002-02-13 2004-08-31 Honda Giken Kogyo Kabushiki Kaisha Electronic control system for vehicle accessory devices
US20030169289A1 (en) * 2002-03-08 2003-09-11 Holt Duane Anthony Dynamic software control interface and method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0696775A1 (fr) 1993-04-21 1996-02-14 Hitachi, Ltd. Système de conception et de production assisté par ordinateur pour la disposition d'éléments et l'interconnexion de tuyaux

Also Published As

Publication number Publication date
WO2004038619A3 (fr) 2004-06-17
EP1556804A2 (fr) 2005-07-27
FR2846117A1 (fr) 2004-04-23
EP1556803A2 (fr) 2005-07-27
KR101002372B1 (ko) 2010-12-17
KR101004302B1 (ko) 2010-12-28
FR2846117B1 (fr) 2008-08-22
WO2004038618A3 (fr) 2004-07-01
JP2006504169A (ja) 2006-02-02
AU2003285418A8 (en) 2004-05-13
AU2003285418A1 (en) 2004-05-13
US7441225B2 (en) 2008-10-21
WO2004038619A2 (fr) 2004-05-06
WO2004038617A2 (fr) 2004-05-06
JP2006504170A (ja) 2006-02-02
KR20050086425A (ko) 2005-08-30
EP1554672A2 (fr) 2005-07-20
KR20050074521A (ko) 2005-07-18
JP2006504171A (ja) 2006-02-02
KR101010975B1 (ko) 2011-01-26
AU2003285417A1 (en) 2004-05-13
US20060215825A1 (en) 2006-09-28
US7912791B2 (en) 2011-03-22
KR20050074520A (ko) 2005-07-18
US20060143587A1 (en) 2006-06-29
AU2003289672A1 (en) 2004-05-13
WO2004038617A3 (fr) 2004-06-17
US20060229742A1 (en) 2006-10-12

Similar Documents

Publication Publication Date Title
EP1556803A2 (fr) Procede et dispositif pour synthetiser une architecture electrique
US11354899B2 (en) Visual inspection support using extended reality
US8065126B2 (en) GUI-facilitated change management for vehicle electrical/electronic architecture design
US8060347B2 (en) Complexity management for vehicle electrical/electronic architecture design
US20100030546A1 (en) Gui-facilitated simulation and verification for vehicle electrical/electronic architecture design
Wozniak et al. How automotive engineering is taking product line engineering to the extreme
Bucaioni et al. Technical architectures for automotive systems
Wedeniwski The Mobility Revolution in the Automotive Industry
EP1387305A1 (fr) Procédé et systeme d'établissement automatique d'un modèle global de simulation d'une architecture
Anselma et al. Next generation HEV powertrain design tools: roadmap and challenges
Kaiser et al. Digital vehicle ecosystems and new business models: An overview of digitalization perspectives
FR2984561A1 (fr) Procede et dispositif de conception solide d'un systeme
Bijlsma et al. Decision support methodology for evolutionary embedded system design
FR2963133A1 (fr) Procede et dispositif pour synthetiser une architecture electrique et electronique.
Ertener et al. System of Systems Based Approach for the Development of Autonomous Ride-Pooling Vehicles
Manabu et al. Intelligence design concept method utilizing customer science
Quezada Gomez Model-based guidelines for automotive electronic systems software development
이민구 Data-driven Design Approaches for Vehicle Specification Changes
FR2963126A1 (fr) Procede d'execution parallele d'une pluralite de taches ordonnees selon une table d'ordonnancement
Sivakumar et al. Role of AUTOSAR in Automotive Software Trends
Nybacka et al. Collaboration in automotive winter testing: Real-time simulations boosting innovation opportunities
Fasuga et al. Collecting unification and presentation of multimedia content and product configurations in multilingual product catalogs
Sadegh Amalnik Design of Computer Integrated Manufacturing System for Irankhodro Auto Industry
Abowd et al. A Strategy for Optimal Design of Embedded Systems with Human Machine Interfaces
東欣一 Systems Modeling of Automotive Electrical and Electronic Architecture

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003778417

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2004546103

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020057007759

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 1020057007759

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2003778417

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006229742

Country of ref document: US

Ref document number: 10532089

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10532089

Country of ref document: US