Abstract:
A software system for use in an electronic control unit (ECU) is designed to facilitate its reuse without redesigning of triggers even when a target hardware is changed. The design of the software system includes a classification of trigger types into two categories, that is, a function trigger and a software trigger, and combination of the function trigger to the software tasks in addition to the association of the function triggers with the software triggers for hardware independent design of the software system.

Description:
CROSS REFERENCE TO RELATED APPLICATION 
     This application is based on and claims the benefit of priority of Japanese Patent Application No. 2006-80844 filed on Mar. 23, 2006, the disclosure of which is incorporated herein by reference. 
     FIELD OF THE INVENTION 
     The present invention generally relates to a software system of electronic control units (ECUs) for use in a vehicle. 
     BACKGROUND INFORMATION 
     In recent years, a software structure such as the one in Japanese patent document JP-A-2001-109628 is proposed for improving an efficiency of reuse of an application software on various different platforms. 
     That is, in the software structure disclosed above, each of plural components in the application software is configured to have an interface and a body to implement a certain function, and is used to compose the application software in a framework that the components in the application software operate independently with each other. In this manner, the reuse of the application software and independency of platforms (hardware) are both realized. 
     Further, the reuse of the software is enabled by using an independent trigger design policy that a trigger, i.e., an event routine (e.g., a type of a script program), for triggering a process in the component is designed independently for each of the components. 
     However, in designing a vehicle control system, the reuse of the software cannot be realized by only designing the trigger independently for each of the components. This is because the software design of each of the triggers must take a corresponding hardware that generates each of the triggers into consideration. 
     For example, when a trigger is periodically generated, that is, when a certain function being triggered by the trigger is periodically used, a timer function of a microprocessor is used to give generation timings for the trigger in general. In addition, when the trigger is used in synchronization with a function implemented by other ECU, synchronicity of a time-trigger type communication protocol such as FlexRay is used for triggering. That is, for example, when the trigger is used periodically in synchronization with a function implemented by other ECU, the timer in a communication controller is used for generating the trigger. Further, when the trigger is used in synchronization with a control request from a function implemented by other ECU, reception of the control request trough a network is used for generating the trigger. 
     Therefore, in the trigger design of vehicle control scheme, consideration of the corresponding hardware is required for all of the above-described cases. As a result, when the hardware for implementing a specific function (i.e., for implementing an application software) is changed, the corresponding trigger has to be re-designed. 
     SUMMARY OF THE INVENTION 
     In view of the above-described and other problems, the present disclosure provides a software system of vehicular ECU (electronic control unit) that can be reused without redesigning a trigger when a corresponding hardware of the trigger is replaced. 
     In one aspect of the present disclosure, the software system for use in a vehicle electronic control unit of a vehicle control network includes plural software components for at least implementing plural vehicle control functions to the vehicle electronic control unit. The plural tasks that are started by electronic control unit software in the vehicle electronic control unit are respectively associated with plural function triggers, and each of the plural function triggers is invoked by at least one of the plural tasks in association with the each of the plural function triggers for implementing the plural vehicle control functions. In this manner, the function design of the software system is conducted independently from hardware. In other words, reuse of the software system on different hardware is facilitated due to the independency of the software system from the hardware design. 
     For example, an event task and periodic tasks are provided for invocation by an event trigger derived from the hardware such as a vehicle control network or a vehicular electronic control unit invocation by periodic trippers derived from a timer function of the vehicular electronic control unit or a synchronization timer of the vehicle control network. 
     In this case, the periodic tasks may retain operation information on operation conditions of the plural software components, and the periodic tasks may not output the function triggers when the operation information indicates non-operation of the plural software components. Therefore, the operation consistency between operation of respective functions and corresponding “runnable entities” that actually implements functional operations of the software system is guaranteed. 
     In addition, the present invention can be represented and grasped as a design methodology of software for use in the ECU. 
     That is, the method of designing a software system used in plural electronic control units of a vehicle control network includes steps of dividing vehicle control functions into plural software components, structuring the plural software components into hierarchical layers, designing an execution sequence of the plural software components by assigning a function trigger to each of the plural software components, implementing each of the plural software components respectively to the electronic control units, preparing structured detail functions for each of the plural software components based on analyzing a function of each of the plural software components, setting function triggers for executing the structured detail functions, and designing software task arrangement by assigning the function triggers to the software tasks. In this manner, the software design is conducted solely independent from the constraints and/or restrictions of a target hardware. Therefore, the reuse of the components in the software system is facilitated. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Other objects, features and advantages of the present invention will become more apparent from the following detailed description made with reference to the accompanying drawings, in which: 
         FIG. 1  shows a block diagram of functional structure of a vehicle control network system in an embodiment of the present disclosure; 
         FIG. 2  shows a time chart of a process sequence of respective components shown in  FIG. 1 ; 
         FIG. 3  shows a block diagram of the vehicle control network system in the embodiment; 
         FIG. 4  shows a block diagram of the vehicle control network system in association with the components shown in  FIG. 2 ; 
         FIG. 5  shows a block diagram of functional structures of the components in association with activation triggers; 
         FIG. 6  shows a time chart of runnable entities in association with triggers and tasks in an engine ECU; and 
         FIG. 7  shows a block diagram of software tasks in association with triggers and runnable entities. 
     
    
    
     DETAILED DESCRIPTION 
     An embodiment of the present invention will be described with reference to the accompanying drawings. 
       FIG. 1  is a block diagram showing a part of a functional structure of a vehicle control network system. There are various other functions included in the vehicle control network system in addition to the functions illustrated therein. However, only functions used in the description of the present invention are shown in  FIG. 1 . 
     As shown in  FIG. 1 , as functions (components) included in the vehicle control network system, for example, there are a vehicle coordinator  101  in the uppermost stream and a vehicle motion coordinator  102  in the downstream thereof. A power train coordinator  103  is used in the downstream of the vehicle motion coordinator  102 , and further in the downstream of the power train coordinator  103 , an engine control component  104  and a transmission control component  105  are used. Moreover, in the vehicle motion coordinator  102 , in addition to the power train coordinator  103 , a brake control component  106  is also used. 
     The vehicle coordinator  101  calculates a required quantity of operation that a driver requests from the vehicle, such as a required acceleration and deceleration speed and a required yaw rate, based on information about driver operations (accelerator pedal and brake pedal operations), and passes the result to the lower vehicle motion coordinator  102 . 
     The vehicle motion coordinator  102  calculates a momentary vehicle motion request to stably achieve a request of vehicle motion based on a driver&#39;s request passed from the upper vehicle coordinator  101 . For example, it passes required values such as required axle torque and required control torque to the power train coordinator  103  and the brake control component  106 , respectively. 
     The power train coordinator  103  calculates required values such as required engine torque and required gear necessary to realize the required values such as required axle torque passed from the vehicle motion coordinator  102  in an upper hierarchy, and passes them to the engine control component  104  and the transmission control component  105 , respectively. In this manner, the control components  104  and  105  control targeted actuators, for example, an engine throttle and an automatic transmission (hereinafter referred to as AT), so as to realize the required values. 
     Likewise, the brake control component  106  performs the above-described control to realize the required drive torque passed from the upper vehicle motion coordinator  102 . For example, it causes the respective wheels to generate brake force by driving motors for pump driving and various control valves in an ABS actuator. 
       FIG. 2  is a drawing showing a time chart of the respective components constituting the vehicle functional structure shown in  FIG. 1 . 
     The vehicle coordinator  101  is activated by a function trigger  211  periodically generated and performs processing in a predetermined period T 1 . In this period, a control request is generated by the vehicle coordinator  101  to the vehicle motion coordinator  102  in a lower hierarchy, and a required quantity of operation that the driver requests from the vehicle is conveyed. 
     The vehicle motion coordinator  102  activates a control request generated by the vehicle coordinator  101  as a function trigger  212  and performs processing in a predetermined period T 2 . In this period, a control request is generated by the vehicle motion coordinator  102  to the lower power train coordinator  103  and brake control component  106 , and required values such as required wheel torque and required control torque are conveyed. 
     The power train coordinator  103  activates the control request generated by the vehicle motion coordinator  102  as a function trigger  213 , and performs processing in a predetermined period T 3 . In this period, a control request is generated by the power train coordinator  103  to the lower engine control component  104  and transmission control component  105 , and required values such as required engine torque and a required speed change step are conveyed. 
     The engine control component  104  is activated by a function trigger  214  independently and periodically generated, irrespective of a generation timing of a control request generated by the vehicle motion coordinator  102 , and performs processing in a predetermined period T 4 . 
     The transmission control component  105  is activated by a function trigger  215  independently and periodically generated, irrespective of a generation timing of a control request generated by the vehicle motion coordinator  102 , and performs processing in a predetermined period T 5 . 
     Likewise, the brake control component  106  is activated by a function trigger  216  independently and periodically generated, irrespective of a generation timing of a control request generated by the vehicle motion coordinator  102 , and performs processing in a predetermined period T 6 . 
       FIG. 3  is a block diagram of the vehicle control network system. ECUs  301  to  304  are connected with one another via a communications line  305  to form the network, and control the entire vehicle by mutually communicating data. 
     The engine ECU  301  controls the engine. The AT-ECU  302  controls the automatic transmission. The brake ECU  303  controls the brake. The vehicle motion ECU  304  performs calculations for stabilizing the motion of the vehicle, and transmits required values to the respective ECUs. The ECUs  301  to  304  concerned in the control of the vehicle are connected to the communication line  305  and perform communications. 
       FIG. 4  shows an example of distributed arrangement of the functions (components) constituting the functional structure shown in  FIG. 2  in the ECUs constituting the vehicle control network system shown in  FIG. 3 . 
     In  FIG. 4 , the vehicle coordinator  101  and the vehicle motion coordinator  102  are used in the vehicle motion ECU  304 , the brake control component  106  is used in the brake ECU  303 , the power train coordinator  103  and the engine control component  104  are used in the engine ECU  301 , and the transmission control component  105  is used in the AT-ECU  302 . 
     Although, in the above description, each function (i.e., component) is used only in one ECU, it does not always need to be used in only one ECU. That is, one function may be split into two or more modules to be implement by plural ECUs. 
       FIG. 5  shows the structure of functions analyzed to refine the respective functions of the power train coordinator  103  and the engine control component  104  that are used in the engine ECU  301 , and activation triggers of the functions. 
     When functions included in power train coordinator  103  are analyzed in detail and structured, they are split into program control logics  501  to  504 . Each of functions thus split corresponds to an execution unit on software, and the execution unit is referred to as a runnable entity (RE). Likewise, the engine control component  104  is split into REs  505  to  509 . 
     The arrows  514  to  522  in the drawing show the flow of data, and represent the passing of calculation results in the REs  501  to  504  and the REs  505  to  508  to a next RE and also an execution order of REs. The arrow  514  represents a control request from the vehicle motion coordinator  102 , which is superior to the power train coordinator  103 , and an I/F between components. 
     Likewise, the arrow  518  represents a control request from the power train coordinator  103  to the engine control component  104 . The arrows  510  to  513  represent function triggers that execute the REs  501  to  509 ; the REs  501  and  502  are executed by a function trigger  510 , the REs  503  and  504  are executed by a function trigger  511 , the REs  505  to  507  are executed by a function trigger  512 , and the REs  508  and  509  are executed by a function trigger  513 . 
     The function trigger  510  is a trigger (PT_EVENT_Trigger) triggered synchronously with the reception of a control request from the vehicle motion coordinator  102 , which is superior to the power train coordinator  103 . The function trigger  511  is a trigger (PT — 8 m_Trigger) triggered every 8 milliseconds. The function trigger  512  is a trigger (PT — 4 m_Trigger) triggered every 4 milliseconds. The function trigger  513  is also a trigger (PT — 8 m_Trigger) triggered every 8 milliseconds. 
       FIG. 6  is a timing chart showing a relationship between the REs  501  to  509  implemented in the engine ECU  301  and the function triggers  510  to  513  and tasks that execute them.  FIG. 7  is a block diagram showing the correspondences between tasks (software tasks)  601  to  603 , and the function triggers  510  to  513 , and the correspondences between the function triggers  510  to  513 , and the REs  501  to  509  run by them. 
     The tasks  601  to  603  are activated by software such as an OS (Operating System) implemented in each ECU, and as shown in  FIG. 6 , the software triggers  604  to  606  cause the tasks to be activated. These software triggers  604  to  606  are triggered by hardware. For example, the software triggers  605  and  606  are triggered by an internal timer of a microcomputer, or by a synchronous timer of the communication line  305  if the communication line is a time-trigger type such as FlexRay. 
     For example, as shown in  FIG. 6 , as an execution trigger of the event task  601  that executes interrupt processing, the software trigger  604  (Trigger_Event_A) triggered on the reception of network data is used. 
     In  FIG. 6 , the software triggers  605  and  606  and the periodic tasks  602  and  603  are added with subscripts (a to d). The subscripts are meant to enable easy understanding of a correspondence between the software triggers  605  and  606  triggered repeatedly in an interval of a fixed cycle, and the periodic tasks  602  and  603  that operate based on them. 
     As shown in  FIG. 7 , the function triggers  510  to  513  that cause the REs  501  to  509  to operate are assigned to (associated with) the tasks  601  to  603 , and the REs  501  to  509  are run by the function triggers  510  to  513 . 
     A software design method in the present embodiment will be described with reference to the above-described  FIGS. 1 to 6 . 
     In vehicle control development, as a first step, the functional structure as shown in  FIG. 1  is designed. In designing the functional structure, the function of the entire vehicle divided into modules, then interfaces for observable quantities (e.g., vehicle speed) of the vehicle necessary for calculations for achieving the function, required values from other functions, and required values to other functions are stipulated. Further, components are constituted based on the interfaces and divided functional modules, and a relationship among the components is defined for a hierarchical structure. In the present embodiment, as shown in  FIG. 1 , as an example, a functional structure for achieving the driving and braking of a vehicle and stability by use of them is put into a hierarchical structure. 
     Furthermore, to allow the function of the entire vehicle to operate normally, conditions and timing of executing the respective components, that is, an execution sequence is designed. Specifically, triggers and function triggers to activate the respective components are assigned. Conditions of triggering the function triggers are defined in a form of events such as periodic and control requests.  FIG. 2  shows an execution sequence in the present embodiment. The function triggers  211  to  216  of the components are set only from the standpoint of function implementation without considering the hardware in any sense. 
     After designing the functional structure, the components are implemented to the ECUs in the vehicle control network system. For example, in the present embodiment, since the vehicle control network system is structured as shown in  FIG. 3 , the components are used as shown in  FIG. 4 . 
     At this point, data flowing through the network is determined. In the present embodiment, control requests that the vehicle motion coordinator  102  sends to the brake control component  106  and the power train coordinator  103 , and a control request that the power train coordinator  103  sends to the transmission control component  105  are exchanged over the network. 
     Although not shown in the drawing, the vehicle is provided with various sensors for observing condition quantities of the vehicle. The various sensors are connected to each ECU, and signals detected by the sensors are used to calculate control quantities in each component. Such observable quantities of the vehicle are communicated over the network, and what observable quantity is communicated is decided depending on the arrangement of functions. 
     After implementing the components in each of the ECUs, software design is performed. In the present embodiment, as an example of software design, software design of the engine ECU  301  will be described. 
     Since the power train coordinator  103  and the engine control component  104  are used in the engine ECU  301  as shown in  FIG. 4 , after performing an analysis for refining functions included in each of the components, REs as execution units of the respective functions are structured, and further function triggers to execute each of the REs are set.  FIG. 5  shows a software structure of those REs, triggers, a component and a coorinator. 
     As shown in the processing sequence of  FIG. 2 , the power train coordinator  103  is executed with a control request from the upper vehicle motion coordinator  102  as a trigger. The control request is the data  514  in  FIG. 5 , and a trigger triggered synchronously with the generation of the request corresponds to the function trigger  510 . When the function trigger  510  is triggered, the power train coordinator  103  is executed. That is, the REs  501  to  504  constituting the power train coordinator  103  are executed. 
     However, in execution timing of a component, all of the REs in the component are not always executed concurrently. For example, consider the case where an RE that performs desired calculations based on temperatures and the like exists in a part of components executed every 16 milliseconds. Since a temperature sensor is normally slow in response, that is, the generation frequency of a detected signal is slow, it is meaningless to execute calculations using data having such a slow frequency in the fast cycle of 16 milliseconds. Therefore, only the RE that performs desired calculations based on temperatures and the like may perform calculations every 100 milliseconds, and passes the result to other REs that operate every 16 milliseconds. This is not problematic with the control of the component itself at all, and also will contribute to reduction in processing loads on the CPU. 
     Therefore, when REs have been structured by refining functions included in the components as described above, with the result that the frequencies of the functions are determined based on functions and the like in the upper hierarchy to the functions concerned, it is desirable to perform a function trigger design according to functions in the upper hierarchy. 
     In the present embodiment, of the REs constituting the power train coordinator  103 , the REs  501  and  502  are executed by the event trigger  510 , which is a function trigger of event type synchronous to a control request from an upper component, and other REs  503  and  504  are executed by the periodic trigger  511 , which is a function trigger periodically triggered every 8 milliseconds. The same is also true for the engine control component  104 . Of the REs constituting the engine control component  104 , the REs  505 ,  506 , and  507  are executed by the periodic trigger  512 , which is a function trigger periodically triggered every 4 milliseconds, and the REs  508  and  509  are executed by the periodic trigger  513 , which is a function trigger periodically triggered every 8 milliseconds. These function triggers are set only from the standpoint of function implementation without concern about hardware. 
     After a detailed design (the splitting of functions and design of function triggers) of functions implemented in each ECU has been decided, a task design is performed to use function triggers in each task as shown in  FIG. 6 . In the present embodiment, as tasks, the event task  601 , the periodic task  602 , and the periodic task  603  are set. These tasks correspond to the software triggers  604  to  606 , respectively, and are activated by the OS or the like, and the software triggers  604  to  606  are triggered by hardware. The software trigger  604  as an event trigger is triggered on the reception of network data. A control request from the vehicle motion coordinator  102  superior to the power train coordinator  103  is brought over the network because the vehicle motion coordinator  102  is used in the vehicle motion ECU  304 , and the software trigger  604  is activated synchronously with the reception of network data. 
     Therefore, the event task  601  that operates with the software trigger  604  as a triggering factor operates synchronously with the control request (network data reception) from the vehicle motion coordinator  102 . 
     The software triggers  605  and  606  as periodic triggers is triggers triggered by a timer function of the microcomputer. In the present embodiment, the software trigger  605  is triggered every 4 milliseconds, and the software trigger  606  is triggered every 8 milliseconds. The periodic trigger may be a trigger triggered by the synchronous timer if the communications line  305  is a time-trigger type such as FlexRay. Therefore, the periodic task  602  operates every 4 milliseconds and the periodic task  603  operates every 8 milliseconds. 
     As described above, when the software triggers  604  to  606  are triggered by hardware, the OS activates corresponding tasks  601  to  603 . The function triggers  510  to  513  to run the REs  501  to  509  are assigned to the tasks  601  to  603 . The function trigger  510  is assigned to the event task  601 . The function trigger  510  is triggered by the operation of the event task  601 , and by the function trigger  510 , the REs  501  and  502  are run synchronously with a control request from the vehicle motion coordinator  102 . 
     For example, it is assumed that, in the power train coordinator  103 , the execution cycle of functions by the REs  503  and  504  is designed as 7.5 milliseconds in the phase of function design. That is, the function trigger  511  is designed as a trigger activated at a cycle of 7.5 milliseconds. In this case, when running the REs  503  and  504  at a cycle of 8 milliseconds causes no problem with implementation of the functions, the function trigger  511  to run the REs  503  and  504  may be assigned to the periodic task  602  that operates every 8 milliseconds. 
     The REs  501  and  502 , which are control logics of the power train coordinator  103 , receive data  514  (see  FIG. 5 ) as a required value of control generated by the upper vehicle motion coordinator  102 , for example, data representative of required axle torque, and process the received required axle torque according to a state of the power train in the vehicle. 
     For example, they process the required axle torque into a realizable required value from vehicle states such as current torque and a vehicle speed. The function trigger  511  is assigned to the periodic task  602 , the function trigger  511  is triggered by the operation of the periodic task  602 , and the REs  505  to  507  are run every 4 milliseconds by the function trigger  511 . 
     The REs  505  to  507 , which are control logics of the engine control component  104 , receive data  518  (see  FIG. 5 ) as required values of control generated by the upper power train coordinator  103 , for example, data representative of required engine torque, and calculate actual control quantities of actuators. They calculate control quantities such as a throttle opening degree, an injection quantity, and ignition timing, based on these control quantities, activate actuators (not shown) constituting the engine, such as an electronically controlled throttle, an electronically controlled fuel injector, and an electronically controlled ignition apparatus, and realize the required engine torque generated by the upper component. 
     The function triggers  511  and  513  are assigned to the periodic task  603 , the function triggers  511  and  513  are triggered by the operation of the periodic task  603 , and the REs  503  and  504  are run every 8 milliseconds by the function trigger  511 . 
     The REs  503  and  504 , which are control logics of the power train coordinator  103  like the REs  501  and  502 , to realize required axle torque calculated (process required axle torque generated by the vehicle motion coordinator  102  according to vehicle conditions) in the REs  501  and  502 , based on the received axle torque, calculate required engine torque and a required gear as required control values to the lower engine control component  104  and the transmission control component  105 . 
     Although the data  518  of the calculated required engine torque is passed to the lower engine control component  104 , it is received and passed inside the engine ECU  301  because both the power train coordinator  103  and the engine control component  104  are implemented in the engine ECU  301 . 
     On the other hand, although the data of the calculated required gear is passed to the lower transmission control component  105 , it is passed on the network through the communications line  305  because the transmission control component  105  is implemented in the AT-ECU  302 . The REs  508  and  509  are run every 8 milliseconds by the periodic trigger  513 . 
     The REs  508  and  509 , which are the control logics of the engine control component  104  like the REs  505  to  507 , calculate data required for the calculation of control quantities of actuators by the REs  505  to  507 . For example, based on sensor values such as an engine speed sensor, an engine water temperature sensor, and an air flow sensor included in the engine although not shown, they calculate estimated engine torque and the like, and deliver the data  522  showing them to the RE  507 . 
     In  FIG. 6 , in the periodic task  603 - b , the function trigger  511  generated by the periodic task  603  when the event task  601  generates the function trigger  510 , and the REs  503  and  504  run by the function trigger are shown by dotted lines. This means that, in the indicated timing, the function trigger  511  is not triggered and the REs  503  and  504  are not executed. 
     Although both the REs  503  and  504  are part of the power train coordinator  103 , since the power train coordinator  103  is a component activated on the generation of a control request from the vehicle motion coordinator  102 , that is, on the generation of the function trigger  510 , the power train coordinator  103  is inactive during operation of the periodic task  603 - b.    
     However, since the periodic task  603  periodically operates, triggering the function trigger  511  at each operation of the periodic task  603  would cause the operation of the REs  503  and  504  without having a function of the power train coordinator  103 . Therefore, by adopting a mechanism for holding operation information the power train coordinator  103  such as a busy and stop state and by refereeing to the operation information at the time of the generation of the function trigger  511 , consistency of the operation of a function (i.e., the power train coordinator  103 ) with the operation of an RE (i.e., the REs  503 ,  504 ) is ensured As has been described above, the function triggers  510  to  513  to operate functions (components) are separated from the software triggers  604  to  606  to actually execute programs on software, and the function trigger  510  is associated with the software tasks  601  to  603 . The function triggers  510  to  513  and the software triggers  604  to  606  are combined during software design. 
     Such a software structure enables function design without concern about hardware. In other words, since influence of a hardware change and a change in function arrangement can be avoided, the reusability of components is achieved. 
     For example, as described in the present embodiment, in the case where a time-trigger type such as FlexRay is adopted for the communication line  305 , and components distributedly used with high precision are synchronously activated, task design is performed based on the software triggers  604  to  606  triggered by an internal timer of the communication controller, and the function triggers  510  to  513  are assigned to the tasks  601  to  603 . Therefore, the contents of function design need not be changed. 
     Moreover, when the vehicle motion coordinator  102  is used in the same engine ECU  301  as the power train coordinator  103 , an only change required for the vehicle motion coordinator  102  is that the software trigger  604  having been triggered on the reception of network data should be triggered on the updating of a control request (the updating of RAM). In other words, the contents of function design need not be changed. 
     Although the present invention has been fully described in connection with the preferred embodiment thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications will become apparent to those skilled in the art. 
     That is, the present invention describes an application of a function structure to the vehicle control network system that employs various vehicle stability control functions for secure implementation of specific vehicle motion controls based on the driver&#39;s request. However, the function structure of the above disclosure can also be applicable, in general, to a different system that includes different control functions from above description. 
     Such changes and modifications are to be understood as being within the scope of the present invention as defined by the appended claims.