专利名称：用于控制汽车驱动设备的控制器和计算机程序的制作方法
技术领域：
本发明涉及一种用于控制一个驱动设备、尤其是汽车内燃机的控制器和计算机程序。
背景技术：
在现有技术中从原理上已知这种控制器和相应的计算机程序。图9示出一个这样的已知控制器，其中标记符号100a代表硬件而标记符号100b代表控制器100的软件。所述控制器100的硬件包括至少一个处理器100a-1和至少一个存储单元100a-2。所述软件100b一般存储在存储单元100a-2里面。该软件100b在现有技术中一般包括多个功能单元VF-1，EF-3，IS-2，HW-1，HW-3和VF-3，它们为了控制驱动设备300至少独立地相互通讯。所述驱动设备300的直接控制借助于一个连接在控制器100与驱动设备300之间的传感器/促动器结构200实现。
在用于控制器100的软件100b中用于控制一个驱动设备的已知功能单元例如是·功能单元驱动VF-1它管理机械能的源并对于驱动设备提供一个理论转矩，用于驱动汽车并用于供给副驱动设备，一般按照给定值通过一个功能单元汽车协调器。
·功能单元汽车协调VF-2它产生关于不同的、也可能是其它功能单元的共同作用的决定。例如它决定，当不同的其它功能单元对于要被调节的驱动设备分别输送不同的转矩值时，功能单元驱动器对于驱动设备应该调节怎样的转矩。
·功能单元汽车运动VF-3它在保证最佳的行驶稳定性方面将汽车的一个实际运动与司机愿望进行比较。例如按照油门和制动踏板上的动作评价司机愿望以及使这个司机愿望与安全系统、如电子稳定程序ESP或反滑差调节ASR的给定值相协调。
·功能单元行驶状态参数VF-4它管理关于实际行驶状态的信息，例如停止或前进，上坡行驶等，与将这些行驶状态通知哪个功能单元无关。
·功能单元马达协调器EF-1该马达协调器的任务是，将其它功能单元的转矩需求通知马达并进行协调并将产生的需求通知转矩变换器。
·驱动设备位置管理器EPM这个功能单元的任务是，获取驱动设备的曲轴和凸轮轴的位置和转速。
·功能单元业务程序库IS-1它的任务是，制备通常非常频繁使用的功能单元，它们由不同的功能单元询问或利用。它有利地提供这些功能单元的集中准备，因此它们不必再多次地非集中地准备。
·功能单元运行控制器IS-2它协调不同功能单元需求的时间上的运算。
·功能单元诊断管理器IS-3这个功能单元承担一个故障信号的处理，该信号例如表示控制器100的硬件100a中的一个缺陷。所述处理尤其是故障信号的脉冲输出和同一故障信号的存储，由此可以在以后的时刻实现故障信号的评价。
·功能单元监控计划IS-4该功能单元尤其用于监控控制器处理器。
·功能单元信号处理器HWE-1它在传感器信号的数字化后在不期望的信号调制方面进行一个模拟传感器信号的纯化，这种信号调制可能在控制器中出现。
·功能单元进汽系统EF-3它的中心任务是，提供关于实际供驱动设备300使用的空气质量的信息并且在其对驱动设备的影响方式范围内监控和调节理论空气质量和/或废气质量。这个功能单元进汽系统尤其用于柴油机或汽油机。
·功能单元喷射系统EF-4它准备所有的用于燃料预输送、产生喷射压力和喷射所需的功能。
在图9中在控制器的软件100b内部示例性地表示各个已知的功能单元。但是它们不是所有的都同时出现并在软件100b中自动编码，而是在持续的研制过程中在一段时间过后才逐步添加到控制器100的软件里面。在添加新的功能单元时目前仅仅注意到，这些新的功能单元可以与所有其它的功能单元进行通讯，如果需要的话。在时间进程中已经在各个功能单元之间出现不明确的节点附聚物，这尤其使得通过修改的功能单元替换已知的功能单元或者继续添加新的功能单元更加困难。因为在各个功能单元之间存在的关系在整个系统转换时或者只转换整个系统的一部分时非常难以看清楚，因此尤其存在着困难。
发明内容
由现有技术提出本发明的目的是，这样改进一个用于控制汽车驱动设备的已知控制器和计算机程序，使得控制器的各个部分尤其与其软件无关地相互独立地实现和更换。
这个目的通过权利要求1的内容得以实现。据此对于一个上述已知的控制器存在一个至少三个模块形式的模块化，其中在第一模块中包括那些功能单元，它们用于在物理层面上以对一个使用者期望的应答影响驱动设备，在第二模块中包括那些功能单元，它们能够以这种方式实现控制器硬件的单独编程，使得硬件置于与控制器模块通讯的位置并且它们使模块中的功能单元的功能运算在时间上协调，并且在第三模块中包括那些功能单元，它们能够以这种方式使所使用的传感器/促动器结构单独地适配于控制器，使得在结构的各个传感器或促动器之间能够实现一个与控制器的其余模块的通讯；并且其中在模块之间具有用于模块搭接通讯的模块节点。
在本发明意义上的驱动设备对于一个内燃机也可以例如是一个电驱动器或一个燃料电池驱动器。
在本发明意义上的使用者例如可以是汽车司机、规则制订者、汽车供应商或汽车生产者。
在本发明意义上的物理层面表示一个硬件规类的概念。它表示，在物理层面中以传感器的节点为基准到其邻域仅仅考虑物理参数例如驱动设备的转速，但是不考虑其硬件方面的具有一个硬件专有的、代表转速的振幅的电信号形式的反应。
本发明的优点所提出权利要求的模块化的主要优点是，可以方便地更换并且相互独立地实现各个模块。在此已经这样选择功能单元在各个模块上的分布，使得它尤其在汽车生产者的观点并且在物理的观点上是有意义的。因此各个模块的更换特别简单，因为在各个模块之间的确定的模块节点中功能单元之间的所有关系都在不同的模块中考虑到；由此引出的关系尽管还可以在功能单元的层面上存在，但是在模块的层面上不再存在并因此在更换模块时不必再考虑。
所建议的模块化尤其节省成本和时间。在使用其它控制器硬件或其它传感器/促动器结构时不必再更换或适配控制器的全部软件，而是只更换相应的模块就足够了。
按照一个第一实施例以有利的方式建议，将第一模块分成一个汽车组元和一个驱动设备组元。按照一个第二实施例建议，将第二模块分成一个次结构组元和一个封闭硬件以及根据情况附加地分成一个通讯组元。
概括上述实施例要注意到，将各个模块区分成与模块近似的组元用于改善组元的更换性。
以有利的方式也在模块内部的组元之间规定用于一个快速更换的节点。与此相反在不同模块的组元之间的通讯通过模块节点实现。每个组元本身又分成任意多的功能单元。节点也位于这些功能单元的层面上，因此不同的功能单元在一个组元内部可以相互通讯。在不同组元的功能单元之间的通讯通过组元节点实现并且在不同模块的功能单元之间的通讯通过模块节点实现。对于功能单元之间和组元之间的节点上述对于模块节点的描述也有效，即在这些节点中在功能单元之间或组元之间相互间的所有必需的关系都被考虑到并且不必分别考虑其它关系。由此不仅产生模块的方便更换性，而且产生组元或功能单元的方便更换性，即，特别方便且不复杂地适配于用户愿望或新的技术。
各个组元和包括在各个组元中的功能单元和元件的任务的详细描述是相应权利要求的内容。
按照一个有利的扩展结构所述功能单元、组元和/或模块以及其那些节点至少部分地构成计算机程序。作为计算机程序的结构允许灵活地转换变化愿望，而不必改变控制器的硬件。
此外上述任务通过一个用于上述和所提出权利要求的控制程序的计算机程序得以实现。这个计算机程序的优点对应于上面在控制程序中所述及的优点。
其它的优点由下面的描述给出。
描述总共九个附图，其中图1为一个按照本发明的用于控制器的模块构造，图2为一个按照本发明的将模块划分成组元，图3为一个按照本发明的功能单元配置成一个汽车组元和一个驱动设备组元，图4为一个按照本发明的功能单元配置成一个次结构组元和一个封闭硬件组元，图5为一个用于控制器驱动元件的功能单元，图6为节点之间的一览图，图7为在不同组元中的两个功能单元之间的节点，图8为模块之间的数据流示例，图9为按照现有技术的控制器结构，图10为按照本发明的节点构造嵌入到模块构造里面，图11为任选节点的层面图。
具体实施例方式
借助于附图给出本发明实施例的细节描述。
图1为以图9为基准示出一个按照本发明的在一个控制器100中的功能单元的模块化结构，该控制器用于控制一个汽车、尤其是一个内燃机的驱动设备300。与图9不同，在图1中仅仅示出存储单元100a-2的内容结构；尤其是所述传感器/促动器结构200和驱动设备300不是本发明的内容并因此在下面不再描述。
按照本发明建议，所述功能单元在控制器100中分成四个独立的模块组合。
在第一模块ASW中包括那些功能单元，它们用于在物理层面上以对一个使用者期望的应答影响驱动设备。
在第二模块CO中一方面包括那些功能单元，它们能够以这种方式实现硬件的单独编程，使得硬件置于与控制器100的模块进行通讯。此外第二模块CO还包括那些功能单元，它们协调功能单元的功能在模块ASW，CO，DE，CD中的运算。此外所述第二模块CO还具有这样的功能单元，它们能够使模块ASW和/或第三模块DE与其它控制器进行通讯。
在第三模块DE中包括那些功能单元，它们能够以这种方式使所使用的传感器/促动器结构实际适配于控制器100，使得在结构的各个传感器或促动器之间实现与控制器100的其它模块的通讯。
最后在一个第四模块CD中包括那些功能单元，它们能够通过第一模块通过到控制器100的复合节点实现复合的传感器/促动器结构的直接控制。这些专用的传感器/促动器结构与上述的非专用的传感器/促动器结构不同。与非专用的配置不同，在其中只通过第二和第三模块实现与第一模块的通讯，在专用配置中直接通过第四模块实现与第一模块的通讯。
在模块ASW，CO，DE，CD之间分别具有节点M1，M2，M3，M4，M5和M6，它们一方面能够实现模块相互间的通讯，但是也能够实现各个模块的更换。
图2示出一个按照本发明的组元在上述模块ASW，CO和CD内部的分组。所述第一模块ASW主要代表针对应用或使用者的功能。在不同类型的驱动设备应该通过控制器进行控制的已计划的应用场合方面有意义的是，将这个第一模块ASW分成一个汽车组元VF和一个驱动设备组元EF。
所述汽车组元最好包括那些功能单元，它们不专用于一个确定类型的驱动设备300。在此，如同上面已经描述过的那样尤其涉及到汽车协调器VF-2，汽车运动VF-3或汽车状态参数VF-4。
所以在驱动设备组元EF中最好包括所有那些功能单元，它们专用于所使用的驱动设备300类型。在此，如同上面以图9为基准所描述的那样，最好涉及功能单元马达协调器EF-1，马达转矩结构EF-2，进汽系统EF-3或喷射系统EF-4。在更换由控制器100控制的驱动设备300时不再需要更换整个第一ASW模块，而是以有利的方式只更换驱动设备组元EF就足够了。
与第一模块类似在第二模块中例如在控制器100中对于另一要使用的处理器建议，将第二模块分成一个次结构组元IS和一个封闭硬件组元HWE。在次结构组元IS中最好包括所有那些功能单元，它们提供或代表基本的业务，其它功能单元可以存取到这些业务。在此，同样如上所述，最好涉及到功能单元业务程序库IS-1，运行控制器IS-2，诊断管理器IS-3和监控计划IS-4。所述业务在次结构组元中集中制备并因此不必出现非集中地多次完成并且无需存储位置。
在封闭硬件组元HWE中包括所有那些功能单元，它们能够以这种方式实现控制器100硬件100a的单独编程，使得所述硬件100a置于与控制器100的模块ASW，CO，DE或CD通讯的位置。因此在通过另一类型的处理器更换在控制器中使用的处理器时仅需更换封闭硬件组元HWE，而无需更换控制器的整个第二模块。
除了上述次结构组元和封闭硬件组元以外所述第二模块CO还具有一个通讯组元COM，在其中包括那些功能单元，它们能够实现与其它控制器的通讯。
除了已经提到的在模块层面上的模块节点M1…M6以外还在各个模块内部的组元层面上具有组元节点。这些组元节点K0…K3能够实现模块内部各个组元之间的数据交换。因此在第一模块中在汽车组元VF与驱动设备组元EF之间存在一个节点K0。在第二模块内部在次结构IS与通讯组元COM之间存在一个组元节点K1，在次结构组元IS与封闭硬件组元HWE之间存在一个第二节点K2并在封闭硬件组元HWE与通讯组元COM之间存在一个第三节点K3。
在图3中示出上述的功能单元分成汽车组元VF和驱动设备组元的配置以及两个组元之间的节点K0。此外还示出，所述功能单元在一个组元内部可以通过功能单元节点Fi相互通讯，i＝1-9。在同一模块内部对应于不同组元的功能单元之间的通讯通过上述组元节点、在这里为K0实现。
图4示出已经描述过的将功能单元在第二模块内部分成次结构组元IS和封闭硬件HWE的配置。已经在借助于图3描述的功能单元与组元之间的节点在这里相应地适用。也可以选择或者附加地对于图3和4所示的功能单元在一个组元内部的功能单元之间的节点结构也可以这样构成这些节点，使得在一个组元内部直接建立起对每个功能单元的连接。因此无需例如在功能单元业务程序库IS-1与功能单元诊断管理器IS-3之间通过功能单元运行控制器IS-2的通讯建立通讯，而是直接建立连接。
对于功能单元HWE-1…N有利的是，将它们区分成一个处理器层面单元和一个硬件概念层面单元。这种区分的优点是，在期望更换处理器时不必更换整个封闭硬件组元HWE，而是只更换处理器层面单元，但是对于封闭硬件组元HWE的所有功能单元。与期望更换控制器的外部硬件相类似，对于处理器以外的控制器硬件同样不必更换整个封闭硬件组元HWE，而是对于HWE的所有功能单元只更换硬件概念层面单元就足够了。
一个对应于封闭硬件组元HWE的功能单元是功能单元信号处理HWE-1，在前面已经描述过它。对于功能单元信号处理HWE-1处理器层面单元HWE-1-1承担信号处理，因此涉及到所使用的处理器类型，处理器层面单元HWE-1-2承担信号处理，因此涉及到在控制器中所使用的外部硬件。
此外还具有节点Ek用于处理器层面单元HWE1-1与硬件概念层面单元HWE1-2相互间和/或与置于其上的HWE中的功能单元HWE-1通讯。
图5表示已经述及的有利地将第四模块CD区分成多个功能单元；这些功能单元参照第四模块也称为复合控制器驱动器CD-i，其中i＝1…N。每个复合控制器驱动器本身有利地分成一个控制器驱动器单元CD-GT和一个硬件驱动器单元CD-HW。所述单元CD-GT通过节点M3连接到第一模块ASW。通过这个节点M3传递软件信号，它们代表一个物理参数如喷射量或转速。当该控制器驱动器单元CD-GT从第一模块ASW接收一个这样的软件信号时，它们将这个信号转换成一个其它的软件信号，它专用于一个要被控制的促动器，但是也非专用地用于控制器硬件。在相反的情况下，当控制器驱动器单元CD-GT从一个硬件驱动器单元CD-HW接收一个这样的其它软件信号时，它们将这个信号转换成一个只代表一个物理参数的软件信号，但是不再是专用于一个传感器，从该传感器产生原始的信号。所述硬件驱动器单元CD-HW用于将专用的传感器/促动器结构200连接到所使用的控制器硬件，尤其是所使用的处理器100a-1。在控制器驱动器单元CD-GT与相应的其它硬件驱动器单元CD-HW之间分别具有节点Ei，i＝1…N。
一个复合控制器驱动器是上述的功能单元驱动设备位置管理EPM。其控制器驱动器单元和其硬件驱动器单元为了表示明确的相应关系具有一个标记符号CDEMP-GT和CDEPM-HW。
图6示例地示出模块节点M2和M4。箭头分别代表通过节点实现的所示模块或其组元之间的关系。在此本描述意味着，一个模块取决于另一模块或者一个组元取决于另一组元，这个模块存取到另一模块或者这个组元存取到另一组元或者说为了根据协议进行处理将数据给到另一模块或另一组元。代表关系的箭头不是必需表示相应的数据流方向；这些数据流方向还要借助于图8描述。由图6可以看出，在第三模块DE与第一模块ASW之间存在一个交换的关系。第一模块ASW与第三模块DE通过从第二模块指向第一模块的箭头代表的关系由这个事实产生，第一模块依赖于第三模块DE例如对于第一模块ASW提供一个传感器信号和/或一个相应的质量信号，它代表一个关于传感器信号质量的信息。
如同由图6还可以看到的那样，第四模块节点M4实现次结构组元和封闭硬件组元相对于第三模块DE的单向关系并且实现通讯组元COM与第三模块DE的交换关系。所有上述的三个组元对应于第二模块CO。所述次结构组元和封闭硬件组元的单向关系意味着，第三模块存取到这些组元，用于能够处理那里的数据。对于第二模块CO与第四模块CD之间的节点M6也存在着如上对于第二模块CO与第三模块DE之间的节点M4所描述的关系。
图7示出在同一模块的不同组元中的两个功能单元之间搭接组元的通讯的示例。准确地说，图7表示在封闭硬件组元HWE内部的功能单元信号处理HWE-1与次结构组元IS内部的功能单元诊断管理器IS-3之间的通讯。在这里功能单元信号处理与功能单元诊断管理器有关。这一点例如意味着，所述功能单元信号处理HWE-1将一个信号发送给功能单元诊断管理器IS-3，通过协议进行处理。所发送的信号例如代表在相应于控制器100的硬件100a中的一个缺陷。通过传递信号功能单元信号处理HWE-1委托功能单元诊断管理器处理这个信号，即例如脉冲输出，使得能够对这个信号实现无误差地评价。除了信号处理以外所述功能单元诊断管理器例如还完成存储这个信号的任务，使得在以后的时刻、例如在一个汽车维修车间为了诊断故障可以读出该信号。
图8仅借助于一个示例性的信号流表示控制器软件100b内部的各个模块的共同作用。与上面已经述及的关系观察相比，一个这样的信号流观察是用于描述各个节点、尤其是模块之间功能的一个可选择的方法。两种观察方法相互间没有矛盾，而是仅仅以不同的方法描述一个节点的功能。
具体地说，在图8中描述那个在一个汽车司机操纵油门踏板时给出的信号，在该汽车中内燃机300安装控制器100。在图8中所述油门踏板或者一个固定在其上的位置检测器通过标记符号200a代表传感器/促动器结构200的传感器。一个代表油门踏板位置变化的信号S1从油门踏板首先传递给控制器100的硬件100a。在控制器硬件100a内部将一个实际的电传感器信号转换成一个软件信号，它首先还是控制器专用的。这个软件信号S2离开控制器硬件100a并存储在第二模块CO，准确地说存储在其封闭硬件组元HWE里面。在那里所述软件信号以这种方式得到处理，使得还包含在其中的控制器硬件100a的影响从其中去掉。在封闭硬件组元HWE的输出上呈现一个纯化的软件信号，它尤其不再含有处理器特征。但是它仍然代表原始电信号的特征，即油门踏板位置的变化，例如以3V振幅的形式。然后将这个纯化的信号S3通过模块节点M4输送到第三模块DE。在第三模块DE中以这种方式对纯化的信号S3进行处理，使得它在一个基于传感器节点的物理层面上转换成其邻域。例如这可能意味着，在第三模块DE的输出上的物理信号S4代表通过第三模块输入上的3V振幅形式的信号S3表示的油门踏板位置变化作为实际值例如以油门踏板可能的旋转角度的75％的形式。所述物理信号S4是第一模块ASW与第三模块DE之间的节点M2的一部分。它从第三模块直接输送到第一模块ASW，准确地说输送到其汽车组元VF。该汽车组元VF阐述该物理输入信号S4作为内燃机300的转矩需求。该汽车组元使这个第三模块的转矩需求与可能存在的其它转矩需求相协调，它们由其它的模块、组元或功能单元提供给内燃机，最终将一个所产生的用于内燃机的理论转矩以信号S5的形式通过组元节点K0传递给驱动设备组元EF。
所述驱动设备组元EF将所接收的理论转矩转换成与内燃机类型相关的物理参数。如果内燃机300是一个柴油发动机，则该驱动设备组元EF产生一个第一调节参数信号S6，它代表物理的理论喷射压力，它为了调节所需的理论转矩是必需的，还产生一个第二调节参数信号S10，它在物理层面上代表为了调节给定理论转矩所需的理论燃料量。根据所产生的用于一个一般促动器或一个专用促动器的理论值是否配有复合的节点，驱动设备组元EF将理论值输出给第三模块DE或第四模块CD。在目前所述的示例中第一理论值S6用于控制一个压力调节阀200b2，该调节阀是一个没有复合节点的一般促动器。因此所述驱动设备组元EF将第一理论值信号S6通过节点M2输送给第三模块DE。该第三模块将输入的物理理论值S6(软件信号)转换成一个软件信号，它以用于控制器硬件100a的非专用电信号S7的形式代表物理的理论压力。这个信号S7通过模块节点M4传递给第二模块CO，在那里被其封闭硬件组元HWE转换成一个软件信号，它代表一个专用于控制器硬件100a的电信号。对于这种转换例如可以是一个适配于控制器硬件要求的量化。由封闭硬件组元HWE产生的和输出的信号S8输送到控制器硬件100a，它将这个信号转换成一个实际的电信号用于控制作为促动器的压力调节阀200b2。
在所述示例中与处理第一调节参数信号S6并行地通过第四模块CD实现第二调节参数信号S10的处理，在第二调节参数信号通过模块节点M3已经传递到第四模块之后。第四模块将代表用于实现所要求的理论转矩所需的物理形式的理论燃料量的信号S10转换成一个软件信号，它代表一个专用于控制器硬件100a的信号。只要第四模块CD同时承担第三模块和封闭硬件组元的功能用于具有复合节点的专用促动器，如同一个用于调节燃料量的喷射阀200b所示的那样。所述的由第四模块CD输出的软件信号S11同样输送到控制器硬件100a，该控制器硬件将这个信号转换成一个用于控制作为促动器的喷射阀200b1的实际电信号S12。这样实现的压力调节阀200b2和喷射阀200b1的控制以通过变化的油门踏板位置代表的司机愿望或代表司机愿望的理论转矩为基准共同影响内燃机300转矩的变化。
如果内燃机300不是一个柴油发动机，而是一个汽油发动机，则由驱动设备组元EF产生三个调节参数信号。第一调节参数信号S6，它输出到第三模块DE，该信号代表一个用于要被调节的空气质量的理论值，输出到第四模块的第二调节参数信号S10代表用于实现理论转矩所需的理论燃料量。此外第三调节参数信号S13同样从驱动设备组元EF输出到第四模块CD，其中该调节参数信号S13定义用于内燃机火花塞的点火时刻。
第一调节参数信号S6用于在转换成信号S7，S8和S9后控制节流阀，第二控制参数信号S10用于在转换成信号S11和S12后仍然控制喷射阀，第三调节参数信号S13用于在转换成信号S14和S15后控制一个火花塞200b3。在图8中在模块或组元内部所示的虚线仅仅表示输入信号到输出信号的配置。它们明确地不包括输入信号在模块或组元内部的处理。
所述功能单元、组元或模块最好由计算机程序实现。能够使这些计算机程序必要时与用于控制驱动设备的其它计算机程序一起存储到一个计算机可读出的数据载体上。在此该载体可以是一个硬盘、一个CD、一个所谓的闪存或类似载体。存储到数据载体上的软件可以作为产品卖给用户。此外在软件实现的情况下可以将计算机程序必要时与其它计算机程序一起没有数据载体辅助措施地通过电子通讯网络作为产品传递给用户并以这种方式销售。对于通讯网络例如可以是互联网。
在目前所述的实施例的一个特殊扩展结构中具体地显示出模块、尤其是DE和CO的输入和输出信号的配置和附属以及其描述。在此引入一个中间模块或一个中间节点SZS，它能够使信号对应于模块、尤其是CO与DE之间。这一点在图10中示出。在其中还如上所述地示出模块CO，CD，DE，ASW。在模块CO与DE之间还示出一个用于使配置数据形成结构的具体节点、即所谓的配置节点KSS。这个节点包括作为主要部分的路由模块用于信号配置即一个信号配置层SZS。这个SZS对应于接近硬件的层，即模块CO。此外一个请求模块或一个请求层AS对应于模块DE。通过这个SZS或整个KSS能够实现一个通用且灵活的信号配置，因此所述模块CO和模块DE可以独立于其相互交换的输入和输出信号或其具体结构地进行设计，因为具体的信号配置在一个中间层、在模块SZS里面实现。
在所选择的附图中模块的配置以有利的方式通过配置参数的XML描述实现，它们通过配置发生器翻译成相应的*.c-和*.h-数据集。这个文献通过基于XML的文字数据集描述软件组数字输入/输出(DIO)的配置。在这个XML数据集中还定义信号等级DIO的特性。DIO特性的描述在不同的工作层面上进行。一方面DIO信号要求具有参数方向、初始化值和使用性(DIO_SIGNAL_REQUEST)的独立于设计的驱动程序封装(DE)，另一方面这些信号必需设计成设计专用的应用，即，信号必需在相应的硬件上运行(DIO_SIGNAL_ROUTING)。必要时必需配置所需的硬件插脚(DIO_SIGNAL_IMPLEMENT)。
不同配置层面的描述在描述数字的输入和输出信号时要区分驱动程序封装(DE)、硬件概念层(HAL＝SZS)和硬件配置(模块CO)。这种要求也发生在其它层之间或者在其余模块之间同样可以使用。任选例如ASW与CO之间作为KSS3或者ASW与DE之间作为KSS4或者ASW与CD之间作为KSS5以及CD与DE之间作为KSS2。在此总是与对于KSS一样输出模块与这里的CO一样作为硬件配置包括一个目标模块，如DE，对于具有一个请求模块或一个请求层AS的KSS包括一个相应层或者一个路由模块SZS。这个基本结构同样可以转移到其余的配置节点KSS2至KSS5。此外只相关地描述KSS，即CO和DE，其中由此同样看出其余节点KSS2-KSS5的应用性。
可以抽象并与设计无关地示出对于DE的组元驱动器重要的配置参数。对于数字的输入和输出信号在这个层面上例如是需求的信号名称、方向和初始化值。在此从组元驱动器的观点来看这是不重要的(保持框架条件为前提)，在组元驱动器上组元驱动器的硬件以后要运行。
所述配置HAL包括信号名路由到相应的硬件。在这个层次中赋予信号一个同类硬件接口名。
硬件专用配置的调节在最底层面上进行。这个层面的配置参数涉及到相应的模块或者信号等级并且已经不再能够与设计和硬件无关地进行考虑。信号的附属通过给出在这个模块上具有所期望的端口或接口的硬件模块(例如ADC/GPIO或CY310，CY100，等)实现。对于ADC模块还必需附加地给出阈值电压，它通过高或低来判断。
寄存器值的调节通过配置硬件层(Layer)端口实现。在这个层面上汇集模块搭接的要求。例如对于并联节点存在不同的模块或信号等级(GPIO，GPTA，SSC，CAN，等)。因此硬件调节不能模块专用地在一个信号等级中实现(也参见配置过程)。
因此DIO配置在不同的配置层面上发生-驱动程序封装DE要求一个信号-硬件封装/HAL＝SZS路由一个信号-硬件配置CO配置硬件层面配置的三个层面层次/数据集/内容DE/数据组名.xml/信号名，方向(进，出)，使用性或存取形式调节(宏或函数)HAL(Routing)/计划.xml/信号名，硬件模块，端口，接口[阈值(ADC)].
硬件配置/硬件.xml/硬件特性，寄存器调节所述配置在不同层面中的分布不局限于数字的输入和输出信号或DIO模块的配置，而是在其它模块(ADC，PWM)中实现相应的上述分级包括例如偏差的配置。
XML配置数据集的名称原则上可以自由选择。在DE内部肯定出现大量针对数据组的配置数据集。在HAL层面上信号路由或者可以分布在一个中心XML数据集里面或者分布在不同的配置数据集上。在此还必需提出，哪些分布最适合于形成计划专用配置的结构。这也同样适用于调节硬件或寄存器配置。
要求一个信号用于DIO(数据组层次-DE)的XML描述<CONF>
<DIO>
<DIO_SIGNAL_REQUEST>
<DESC> 中断信号 </DESC>
<DIO_SIGNAL_NAME>E_A_BRK</DIO_SIGNAL_NAME>
<DIO_DIR>IN</DIO_DIR>
<DIO_CALIBRATION>YES</DIO_CALIBRATION>
<DIO_INIT>HIGH</DIO_INIT>
</DIO_SIGNAL_REQUEST>
</DIO>
</CONF>
在这个层面上从DE的数据组要求一个信号。每个数据组可以存放一个或多个具有任意数据名的XML数据集并且要求或存储CORE/HWE/DIO模块的输入和输出信号。为此必需使用于DIO(数据组层次-DE)的XML描述的数据组语法复制并适配于这个XML数据集。
在上面的示例中确认，一个名称为E-A-BRK的信号在数据组DIO中使用，它具有一个确定的方向(在这里IN用于输入)并且可使用为是或不(在此YES用于可使用)(可使用表示，信号路由对于运行时间借助于一个信号表产生并因此在运行期间可以变化。如果信号数据仅仅用于编译时间，则信号对于运行时间可以不再变换)。不同信号的配置可以在一个XLM中任意次地重复。
注意标签＜DIO-CALIBRTION和DIO-INIT＞是任选的标签。只有在从DE层次已经在前端存在对存取形式或初始化的要求时，才能够确定这些标签。在这些标签中涉及一个配置期望。如果在HW层面上进行偏差的调节，则改写DE层次的要求并一起存入在记录数据集里面(参见数据集节录tmp/include-tmp/dio-report.txt)。
路由一个信号用于DIO(计划层次-HAL)的XML描述<CONF>
<DIO>
<DIO_SIGNAL_ROUTING>
<DESC> 中断信号 </DESC>
<DIO_SOURCE>E_A_BRK</DIO_SOURCE>
<DIO_TARGET>GPIO_P8_P0_IN</DIO_TARGET>
</DIO_SIGNAL_ROUTING>
</DIO>
</CONF>
在这个层面上由计划执行信号路由。因此对软件信号名赋予一个硬件接口名。这个硬件接口名由所期望的硬件资源给出，它配置在硬件层次里面(参见硬件层次的配置)。
在用于DIO(计划层次-HAL)的XML描述的示例中确认，一个名称为E-A-BRK的信号在具有描述(DESC)“Break signal”的数据组DIO中使用并且应该对应于一个确定的硬件接口名“GPIO-P8-P0-IN”(端口“8”，接口“0”，地址“IN”)(“GPIO”用于并联节点存取)。不同信号的配置可以在一个XML数据集中任意多次地重复。
配置硬件层次用于DIO(硬件层次)的XML描述<CONF>
<DIO>
<DIO_SIGNAL_IMPLEMENT>
<DESC>硬件资源用于中断信号</DESC>
<DIO_MODULE>GPIO</DIO_MODULE>
<DIO_PORT>8</DIO_PORT>
<DIO_PIN>0</DIO_PIN>
<DIO_DIR>IN</DIO_DIR>
<DIO_CALIBRATION>YES</DIO_CALIBRATION>
<DIO_INIT>HIGH</DIO_INIT>
</DIO_SIGNAL_IMPLEMENT>
</DIO>
</CONF>
TC1775/TC1796的硬件特性与功能的调节分开并在一个独立的配置层次(HW层)中定义。每个计划可以存放一个或多个具有任意数据集名的XML数据集并且模块以及其端口和接口(最终等级和接口)对应于确定的特性。这些模块必需在功能上处于读出和给出数字信号。为此必需将用于DIO(硬件层次)的XML描述的语法复制并适配于这个XML数据集。
在上述示例中确定，一个名称为“GPIO”的模块在具有描述(DESC)GPIO-P8-P0-IN的数据组DIO中使用(GPIO处于并联节点)。由这个模块要求资源(端口8，接口0)并且赋予使用标识YES以及初始化值HIGH(只要这一点在此对于一个输入是有意义的)。不同信号的配置可以在一个XML数据集中任意多次地重复。
同类硬件接口名所述硬件接口名是一个纯粹的同类名，它明确地对应于一个硬件资源并且按照下面的模式一起调节。
<模块名>-P<端口名>-P<接口名>-<方向>，例如GPIO-P8-P0-IN。
所述硬件接口名可以按照DIO配置过程取自报告数据集(参见下面的同类硬件接口名)。
摘录自数据集tmp/include-tmp/dio-report.txtDIO ReportSignal Map-Digital Input/Output Signals信号名输出OutputHW SignalGPIO-P9-P0-OUT模块ModuleGPIO端口Port9接口Pin0校准CalibrationYES信号名输入InputHW SignalGPIO-P9-P4-IN
模块ModuleGPIO端口Port9接口Pin4校准CalibrationYES信号名输出Input2HW SignalGPIO-P9-P8-IN模块ModuleGPIO端口Port9接口Pin8校准CalibrationYES提示很显然，XML单元＜DIO-CALIBRATION>和<DIO-INTI>分别在两个不同的层次上出现。两个XML单元是任选的，即，如果它们不是明显地给出，则由下面的缺省调节输出<DIO-CALIBRATION>NO</DIO-CALIBRATION>
<DIO-INTI>LOW</DIO-INTI>
如果这个XML单元不仅在DE层次(要求一个信号)上出现，而且在配置硬件层次上出现，则在硬件层次中的调节向上优先到计划层面。在此假设，所述计划层面进行专用的调节并且也可以相对于DE层次渗透。可能的重叠被一起记录并且可以在配置过程后看出。
寄存XML配置数据集在按照要求一个信号执行配置并路由一个信号之后必需将所存储的XML数据集加入到单元CONF下的那些宏命令里面，见插图5宏命令具有插入的XML配置数据集。
宏命令具有插入的XML配置数据集#----------------------------------------------------------------------------#定义模块#----------------------------------------------------------------------------NAME ＝dioINTERFACE ＝dio.hCONF ＝dio_request.xml dio_routing.xml dio_implement.xmlCSOURCES ＝dio.c gpio.cASMSOURCES＝IMPLEMENTATION＝DATA ＝SUBDIRS ＝diocfg输入配置数据配置数据的输入通过一个XML浏览器(例如XMetal)实现。借助于一个用于配置微计划的文献类型定义(DTD)给出XML结构。用于配置微计划的DTD在dem edc_hwe vob上位于微计划中的\scripts\xml\medc17-conf.dtd。这个DTD从Core数据组(模块)的发展相应地连续扩展到宽调节的、可配置的数据。XML配置数据集必需通过这个DTD合理化。
配置过程通过分布在不同的配置层面能够没有详细了解地通过其它层面的配置方式在不同的层面上进行调节。
在此只需给出对于要被配置的层面事实上重要的配置参数。
在图11中示出相应的层模块。
借助于数字输入和输出信号的描述能够更加清楚地解释这个过程。在最上层(DE)中对信号等级DIO提出一个信号要求。除了方向、初始化值和参数使用性以外是信号名，通过它使来自DE的要求与HAL中的路由逻辑运算。在HAL中可以使信号名路由到相应的资源。在HAL中具有调节的计划通过信号名或接口的硬件接口名实现。在硬件层面中除了模块名以外还必需给出相应的端口或接口。对于端口硬件如寄存器位置的特性独立地通过端口配置进行。各个层面的配置通常分布在不同的XML数据集上。配置发生器的任务是检验配置的数据并使它们合理化。
配置发生器在调出微计划中的“宏”和“宏xm12conf”命令后借助于寄存的XML配置数据集产生一个用于已申请的配置数据集的数据清单。以此为基础用于配置的中心XML剖析器(以前的core-parse.pl)汇集所有的配置数据集或数据。在连接到分析过程中起动单独的配置发生器并且产生相应的*.c-和*.h-配置数据集。
所述配置发生器附加地检验数据密度并使用户数据合理化。在有效地结束“宏运行”之后可以在控制器编码中使用配置的信号。
权利要求
1.一种控制器(100)，具有至少一个处理器(100a-1)和至少一个存储单元(100a-2)，该控制器用于通过连接在控制器(100)与一个汽车的驱动设备(300)之间的传感器/促动器结构(200)控制该驱动设备(300)、尤其是一个内燃机，其中通过多个存储在存储单元(100a-2)中的功能单元之间的通讯实现所述控制，其特征在于第二近硬件的模块(CO)，它与第三远硬件的模块(DE)通过一个信号对应节点(SZS＝HAL)连接，它使一个模块的数字信号对应于另一模块，其中近硬件与远硬件是相对处理器而言。
2.如权利要求1所述的控制器，其特征在于，包括第一模块(ASW)，在其中包括用于在物理层面上以对一个使用者期望的应答影响驱动设备的功能单元。
3.如权利要求1所述的控制器，其特征在于，所述第二模块(CO)的设计，使得在其中包括下述功能单元，它们能够实现控制器硬件的单独编程，使得硬件置于与控制器(100)的模块通讯的位置并且它们在模块中在时间上协调功能单元功能的运算；所述第三模块(DE)的设计使得在其中包括下述功能单元，它们能够使所使用的传感器/促动器结构(300)单独适配于控制器(100)，使得在结构的各传感器或促动器之间通过控制器的其余模块实现通讯；并且其中在模块(CO，DE)之间具有用于一个搭接模块的通讯的模块节点(M1...M5)。
4.如权利要求2和3所述的控制器(100)，其特征在于，所述第一模块(ASW)具有-一个汽车组元(VF)，在其中包括不专用于一个确定使用类型的驱动设备(300)的功能单元；和-一个驱动设备组元(EF)，在其中包括专用于所使用类型的驱动设备(300)的功能单元。
5.如上述权利要求中任一项所述的驱动设备(100)，其特征在于，所述第二模块(CO)具有-一个次结构组元(IS)，在其中包括下述功能单元，它们提供或代表基本业务，在其上可以存取其它功能单元；和-一个封闭硬件组元(HWE)，在其中包括下述功能单元，它们能够以这种方式实现控制器(100)的硬件(100a)的单独编程，使硬件置于与控制器(100)的模块(ASW，CO，DE，CD)通讯的位置。
6.如权利要求5所述的控制器(100)，其特征在于，所述次结构组元(IS)最好包括功能单元业务程序库(IS-1)、运行控制器(IS-2)、诊断管理器(IS-3)和/或监控计划(IS-4)。
7.如上述权利要求中任一项所述的控制器(100)，其特征在于，所述控制器(100)具有第四模块(CD)，在其中包括下述功能单元，它们能够通过第一模块通过到控制器的复合节点直接控制专用的传感器-促动器结构。
8.如上述权利要求中任一项所述的控制器(100)，其特征在于，所述功能单元、组元和/或模块以及其之间的节点至少部分地由计算机程序构成。
9.一种用于如权利要求1至7中任一项所述的控制器(100)的计算机程序，用于控制一个汽车的驱动设备(300)，包括一个程序编码，它适合于映射功能单元、组元或模块并且为了控制驱动设备实现其间的通讯。
全文摘要
本发明涉及一种用于控制一个汽车驱动设备(300)的控制器(100)和一个计算机程序。通常在这样的控制器(100)中具有大量功能单元，例如驱动功能单元、马达协调功能单元、诊断管理功能单元等。为了尤其在更换由控制器控制的驱动设备的情况下不必更换所有或绝大部分功能单元，而是只更换对于新的驱动设备重要的功能单元，按照本发明建议一种功能单元的模块化。这种模块化尤其用于使那些功能单元组合在一起，它们能够以这种方式实现控制器硬件的单独编程，使得硬件置于与控制器(100)的调制器通讯的位置。
文档编号F02D41/26GK1754135SQ200480004838
公开日2006年3月29日 申请日期2004年2月19日 优先权日2003年2月21日
发明者B·博伊特尔 申请人:罗伯特·博世有限公司