用于监控由设备访问设备的驱动程序使用的资源的监控单元和方法

摘要

描述了一种用于访问现场总线系统的现场总线组件的设备访问装置。设备访问装置安装在主机或主机环境中，并且包括框架应用以及被绑定到框架应用中的至少一个驱动程序，该驱动程序被设计为访问至少一个现场总线组件。此外，设备访问装置包括监控单元，该监控单元被设计为记录关于由驱动程序预留并由主机或主机环境的操作系统提供的资源的信息，并且在检测到由驱动程序预留的资源的异常的随时间增加时，启动至少一个预定对策。

说明书

技术领域

本发明涉及一种用于访问现场总线系统的现场总线组件的设备访问装置。此外，本发明涉及一种自动化系统。此外，本发明涉及一种用于监控设备访问装置的操作的方法。

背景技术

在自动化技术中，通常应用现场设备，其用于记录和/或影响过程变量。这种现场设备的示例是料位测量设备、质量流测量设备、压力和温度测量设备等，它们作为传感器记录相应的过程变量、料位、流量、压力和温度。

为了访问现场总线系统的现场总线组件，需要大量的驱动程序，这些驱动程序被放置在框架应用中。这些驱动程序通常由现场总线组件的制造商提供。已经发现，由制造商提供的驱动程序具有不同的软件质量，并且在操作期间可能带来问题，这可能导致系统崩溃。

发明内容

技术问题

本发明的目的是能够持久地操作设备访问装置。

该目的通过权利要求1、14和15中阐述的特征来实现。

在从属权利要求中阐述了本发明的有利的进一步发展。

技术方案

与本发明的实施例的形式相对应的设备访问装置用于访问现场总线系统的现场总线组件。设备访问装置被安装在主机或主机环境中，并且包括框架应用和绑定到框架应用中的至少一个驱动程序，该驱动程序被设计为访问至少一个现场总线组件。该设备访问装置包括监控单元，该监控单元被设计为记录关于由驱动程序预留并由主机或主机环境的操作系统提供的资源的信息，并且在检测到由驱动程序预留的资源的异常的随时间增加时，启动至少一个预定对策。

通常，在框架应用中绑定多个不同的驱动程序，其中，现场总线系统的现场总线组件可以通过这些驱动程序来访问。借助于这些驱动程序，现场总线组件可以被配置和参数化。此外，例如，设备状况的监控是可能的。在正常情况下，为现场总线系统的每个现场总线组件提供专用驱动程序，其通常由现场总线组件的制造商提供。这导致这样的事实：通常，来自不同制造商的驱动程序被绑定到框架应用中。已经发现，并非所有由现场总线组件的制造商交付的驱动程序都满足通常的编程质量标准。已经发现，当驱动程序预留由操作系统提供的资源，然后在这些资源使用之后不释放这些资源时，尤其会出现问题。驱动程序要求的资源可以是例如存储器空间、句柄、线程或网络连接以及由主机或主机环境的操作系统提供的其他资源。当这样的资源在它们使用之后没有被释放时，发生由驱动程序要求的资源的异常增加。异常增加尤其意味着例如由于忽视通常的编程标准而引起的预留的资源的增加。这可能导致性能损失，尤其是设备访问装置的操作减慢。此外，不断增加的资源需求也可能导致主机或主机环境的操作系统崩溃。

为了及早检测这样的问题，在设备访问装置中提供了监控单元，该监控单元监控由驱动程序要求的资源。为此，监控单元可以被设计为例如从主机或主机环境的操作系统检索并且随着时间跟踪反映资源预留的参数。当监控单元检测到驱动程序要求的资源异常增加时，监控单元可以启动合适的对策。例如，监控单元可以通知用户该问题、联系支持机构，诸如支持团队、启动驱动程序的重新安装，例如驱动程序的更新版本、启动主机或主机环境的重新启动、执行存储器转储(memory dump)等。由监控单元启动的对策可以防止设备访问装置的性能损失以及系统崩溃。这增加了客户的接受度。此外，可以检测编程不良的驱动程序并提示其制造商消除这些问题。通过这些措施，持久地提高了设备访问装置的软件质量，使得能够实现设备访问装置的稳定操作。

对应于本发明的实施例的形式的自动化技术的系统包括具有至少一个现场总线组件的现场总线系统以及安装在主机或主机环境中的设备访问装置。该设备访问装置包括框架应用和绑定到框架应用中的至少一个驱动程序，该驱动程序被设计为访问现场总线系统的至少一个现场总线组件。该系统包括监控单元，该监控单元被设计为记录关于由驱动程序预留并由主机或主机环境的操作系统提供的资源的信息，并且在检测到由驱动程序预留的资源的异常的随时间增加时，启动至少一个预定对策。

与本发明的实施例的形式相对应的方法用于监控安装在主机或主机环境中的设备访问装置的操作。设备访问装置被设计为访问现场总线系统的现场总线组件。设备访问装置包括框架应用和绑定到框架应用中并被设计为访问现场总线系统的至少一个现场总线组件的至少一个驱动程序。该方法包括记录关于由驱动程序预留并由主机或主机环境的操作系统提供的资源的信息，评估由驱动程序预留的资源的随时间的过程，并且在查明由驱动程序预留的资源的异常的随时间增加的情况下，启动至少一个预定对策。

附图说明

现在将基于附图中所示的实施例的示例更详细地解释本发明。附图示出如下：

图1是现场总线网络和相关联的设备访问装置的结构，相关联的设备访问装置是具有绑定在其中的驱动程序的设备访问软件的形式；

图2是被设计为从操作系统的调试接口检索信息的监控系统的示意图；以及

图3是作为时间的函数的曲线图，示出了所要求的存储器的平均稳定增加。

具体实施方式

图1示出了包括多个现场设备和网关设备的现场总线网络100。现场录入设备101位于现场总线网络100的最上层。现场录入设备101例如经由PROFIBUS分段102与现场设备103和网关设备104连接。PROFIBUS分段102经由网关设备104与HART现场设备105和106耦合，其中，网关设备104被设计为将数据业务从PROFIBUS协议转换为HART协议，反之亦然。

现场总线网络的现场设备的参数化、配置和状态监控借助于安装在主机107中并包括框架应用109的设备访问软件108来进行。主机107经由以太网连接110与现场总线网络100连接。现场总线网络100的各种组件可以经由设备访问软件108来访问。特别是经由设备访问软件108，可以读出、显示和改变现场总线网络100的不同组件的参数。此外，设备访问软件108允许现场总线网络100的组件的状况监测。这些任务所需的数据交换通常经由所谓的非循环数据业务进行。

为了能够正确地访问现场总线网络100的不同组件，框架应用109需要关于现场总线网络100的现场设备、网关、远程I/O等的属性和参数的信息。该信息通常由不同设备的制造商以设备驱动程序或设备描述文件的形式提供。在现场总线协议PROFIBUS-DP、PROFIBUS-PA、FOUNDATION现场总线和HART的情况下，用于非循环数据交换的设备描述是根据标准DTM(设备类型管理器)、DD(设备描述)、EDD(增强设备描述)以及FDI设备包的设备描述。特别是在标准EDD和DTM的情况下，除了设备参数、设备功能和地址空间分配之外，为了便于现场设备的参数化和配置，还预先确定了图形特征和图形用户界面。为了在标准EDD中产生这些图形界面，提供了以解释器语言的方式处理的特殊图形命令。

在标准FDT/DTM中，DTM(设备类型管理器)以动态可加载库(DLL)的形式或以可执行文件(可执行文件)的形式提供。DTM还包括所提到的图形特征。用于现场总线网络的不同组件的不同DTM被绑定到共享FDT框架应用中，其中，FDT代表“现场设备工具”。因此，提供共享框架应用，不同设备以及来自不同制造商的DTM可绑定到共享框架应用中。FDT标准在过去几年中越来越多地被补充，并且以后将可能被标准FDI设备包替代。

除了前面讨论的现场总线协议PROFIBUS、FOUNDATION现场总线和HART之外，还可以提及所谓的工业以太网协议，其中，现场总线协议Ethernet/IP、Profinet和EtherCAT等属于这些协议。在现场总线协议、以太网/IP的情况下，提供对应于标准EDS(电子数据表)的设备描述文件，用于描述循环和非循环数据交换。

在图1的示例中，设备访问软件108优选地包括标准FDT(现场设备工具)的框架应用109，其中，用于现场总线网络100的不同设备和组件的不同驱动程序可以被绑定到框架应用109中。绑定到FDT框架应用中的可以是例如来自不同制造商的不同设备类型管理器(DTM)。除了DTM之外，其他设备描述文件也可以被绑定到框架应用109中。在这种情况下，在驱动程序或设备描述文件的帮助下，现场总线网络100的层次结构在设备访问软件108内被模仿，其中，驱动程序或设备描述文件的布置在这种情况下对应于现场总线网络100的结构的镜像。为了访问现场总线网络100的组件，例如，可以将多个不同的设备DTM、网关DTM和通信DTM绑定到框架应用109中。在DTM层次结构的最高位置是通信DTM 111。通信DTM 111对应于现场录入设备101，并通过以太网连接110与现场录入设备101通信。通信DTM 111表示设备访问软件108的外部接口，其中，所有输入和输出数据业务都经过通信DTM 111。

设备DTM 112在DTM层次结构中被布置在通信DTM 111下方。设备DTM 112映射现场设备103的功能。还在通信DTM 111下方的层布置网关DTM 113，其对应于网关104。经由网关DTM 113，可以参数化和配置网关104。在DTM层次结构中的网关DTM 113下方布置有两个设备DTM 114、115。经由设备DTM 114、115，可以访问现场设备105、106。除了标准FDT/DTM之外，还存在用于设备访问软件108和其中绑定的大量设备驱动程序的替代标准。

基于从用于各个设备的DTM检索的信息，FDT框架应用可以向用户图形地，优选地以树结构的形式，显示现场总线网络100的分层结构。

现场总线网络100可以例如包括不同制造商的现场总线组件。通常，现场总线组件的制造商为现场总线组件提供驱动程序，使得在正常情况下，不同制造商的驱动程序被绑定到框架应用109中。已经发现，这些驱动程序可以具有非常不同的软件质量。例如，当驱动程序要求由操作系统提供的资源，并且在使用资源之后，无法正确地释放它们时，存在驱动程序的较差编程质量。这种行为导致驱动程序的资源消耗稳定增加。

由操作系统提供的资源可以是例如存储器空间、句柄、线程或从驱动程序发出的数据业务。这些资源由操作系统管理，操作系统因此也执行它们的预留和释放。

由操作系统提供的资源的第一示例是存储器空间。例如，驱动程序可以包括表，在操作期间将新条目插入到该表中。与良好的编程规则相反，当为条目分配的存储器空间在使用后没有被释放时，为表分配的存储器空间的大小稳定地增加，这在一段时间后导致操作系统崩溃。

由操作系统提供的资源的另一示例是用于图形显示元素的句柄，所谓的GUI句柄，其中，GUI代表“图形用户界面”。当驱动程序预留这样的句柄并且在使用之后没有适当地释放它们时，那么驱动程序预留的句柄的数量在操作期间稳定地上升。然而，由于操作系统可分配的句柄的数量是有限的，因此增加的句柄数量也不可避免地导致操作系统的崩溃。

线程是由操作系统提供的资源的另一示例。被称为线程的是执行线程，因此是进程内的顺序处理过程。在这种情况下，每个线程(即程序线程)负责执行某个任务。程序功能的执行线程可以以这种方式被划分为可管理单元。进程可以包括多个线程，或者当在程序执行的情况下不提供并行处理时，也可以仅包括单个线程。线程在进程内共享处理器、存储器和其他操作系统相关资源，诸如文件和网络连接。因此，线程的管理工作通常小于进程的管理工作。线程的重要效率优点在于，一方面，与进程相反，在线程交替的情况下，进程上下文的完全交替不是必需的，因为所有线程使用进程上下文的共享部分。另一方面，在线程之间存在容易的通信和快速的数据交换。在线程的情况下，可能发生驱动程序启动多个线程，这些线程在其执行之后未被适当地结束。在这种情况下，由驱动程序启动的线程的数量稳定地增加。由于操作系统只能管理有限数量的线程，这也可能导致操作系统崩溃。

驱动程序要求的资源的另一个示例是从驱动程序向外引导的网络业务。当驱动程序被编程为使得向外定向的网络业务持续增加时，这也将在一定时间之后导致问题，并且在给定情况下导致系统崩溃。

为了检测和克服由不正确编程的驱动程序和不断增加的资源消耗带来的这些问题，根据本发明的实施例的形式的设备访问软件108包括监控单元116，其被设计为监控由驱动程序预留的资源，以检测资源预留的异常增加，并且在这种增加的情况下发起对策。在图1所示的实施例的形式的情况下，监控单元116体现为框架应用109的一部分。可替代地，可以将监控单元实现为设备访问软件108的一部分，然而，实现为与框架应用109分离的单元，诸如图1中的虚线所示。

图2示出了监控单元116，其被设计为检测绑定到设备访问软件108中的驱动程序对资源的过度和异常要求。为此，监控单元116包括数据接口200，监控单元116可以经由数据接口200访问操作系统202的调试接口201。调试接口201可以是例如由Windows操作系统提供的Windows调试接口。经由调试接口201，监控单元116可以检索操作系统的参数，特别是参考存储器空间、句柄、线程和向外定向的网络业务示出操作系统的当前资源预留的参数。可由监控单元116经由调试接口201和数据接口200检索的参数可以是例如由驱动程序要求的存储器空间、给予的句柄的数量、活动线程的数量或向外定向的网络业务的数据速率。

所选参数的提取和评估由命令语言的命令序列控制。为此，监控单元116包括解释器单元203，其被设计为处理命令语言的命令序列204。例如，可以以脚本205的形式提供命令204。命令204可以包括例如循环命令，以便经由调试接口201以规则的时间间隔从操作系统202检索所选择的参数。这样记录的参数值可以例如被存储在监控单元116中。以这种方式，反映驱动程序的资源预留的参数可以被记录为时间的函数并跟踪，以便以这种方式能够监控资源预留。

在图3中绘制了曲线图300，其显示了表示根据时间由驱动程序预留的存储器的参数的值。可以看出，作为各个驱动程序的活动的结果，存储器预留经受时间波动，然而，其中，除了这些波动之外，存在稳定上升的存储器预留，这在图3中由虚线301示出。由驱动程序要求的平均稳定上升的存储器量表明存在至少一个驱动程序没有正常地释放曾经要求的存储器空间。随着图3所示的存储器预留的稳定增加，主机107中的设备访问软件108的持久稳定操作是不可能的。相反，在一定时间之后，预期操作系统崩溃。此外，在由操作系统提供的其他资源的情况下，诸如句柄的数量、线程的数量以及向外定向的网络业务的带宽，随着时间的稳定增加表明所要求的操作系统的资源没有被适当地释放，这又导致在这些示例的情况下也可预见的问题。

为了评估从操作系统202的调试接口201检索到的参数，在监控单元116中提供了评估单元206，其被设计为根据时间跟踪所检索的参数，并且检测操作系统的预留的资源的异常增加。为此，评估单元206可以例如根据时间记录参数，然后基于此来分析是否存在异常的随时间增加。例如，评估单元206可以为此检测参数的随时间增加是否超过预定极限值。

当评估单元206确定存在驱动程序所要求的操作系统202的资源的异常的随时间增加时，那么评估单元206在第二步骤中查明绑定到框架应用109中的驱动程序中的哪一个对所要求的资源的异常增加负责。为此，评估单元206可以跟踪例如哪个驱动程序要求存储器空间、请求句柄、启动线程或导致网络业务。以这种方式，可以识别对预留的资源的异常增加负责的一个或多个驱动程序。以这种方式，可以在系统崩溃发生之前定位潜在的问题。就此而言，监控单元116可以被认为是自动调试单元，其在正在进行的操作期间执行连续的系统监测。

当监控单元116检测到与驱动程序要求资源有关的问题时，可以启动一个或多个合适的对策。在下文中，现在将讨论一些可能的对策。在每种情况下，下面描述的对策也可以以任何组合使用。

一种可能的对策是在显示器或其他合适的显示单元上，例如，也借助于发送到移动设备的报告，向用户指示存在驱动程序越来越多地要求资源的问题。例如，用户可以被告知系统的存储器需求、所使用的句柄的数量、启动的线程的数量或向外定向的网络业务呈向上趋势。另外，当鉴于不断增加的资源消耗时，可以向用户示出预期系统崩溃的预测。然后，用户可以估计还有多少时间用于解决问题。另外，还可以显示用于识别异常工作驱动程序的信息。

另一种可能的对策是例如，按照电子邮件，将关于问题的信息自动转发到支持机构，例如支持团队。这样的支持团队可以例如由框架应用的生产者或现场设备制造商操作。可替代地，制作商协会或制作商总体组织可以维护支持团队。在接收到问题报告之后，支持团队的成员然后可以例如与用户接触并提供关于如何解决问题的信息。作为替代或补充，支持团队的成员可以按照远程访问与主机交互并消除问题。例如，成员可以按照远程访问执行问题驱动程序的重新安装、安装驱动程序的更新版本或重新引导系统。

特别有利的是，关于由驱动程序引起的问题的问题报告被发送到中央机构，例如，被发送到制造商协会或其他包含制造商的组织，其从大量用户接收问题报告。通过评估问题报告，尤其可以发现哪些驱动程序正异常地要求资源。在这种情况下，可以联系并请求受影响的驱动程序的生产者以提供更正的驱动程序版本。

在由过度要求资源引起的问题的情况下，另一种可能的对策是将关于问题的信息从监控单元116写入云207中，其中，来自不同现场总线系统的问题报告被收集在云207中。基于在云207中收集的问题报告，然后可以执行评估，以便查明哪些制造商的哪些驱动程序经常引起与资源的异常要求相关的问题。然后可以请求受影响的制造商提供相关驱动程序的更正版本，以便能够可靠地操作设备访问软件108。

在检测到驱动程序对资源的超相关要求之后的另一可能对策是重新安装相关驱动程序或安装驱动程序的更新版本。通过驱动程序的重新安装，至少可以确保预留的资源被释放，从而防止系统崩溃。相反，安装较新版本的驱动程序提供了较新版本的驱动程序适当地工作的机会，使得由驱动程序引起的与稳定增加的资源要求有关的问题不再存在。为了查明是否存在相关驱动程序的更新版本，监控单元116可以例如将当前安装的驱动程序的版本与可用于相关现场总线组件的最新驱动程序的版本进行比较。为了重新安装现有的驱动程序或更新版本的驱动程序，一方面，有机会借助于为其提供的提示，逐步引导用户通过安装过程。在安装过程结束时，可以例如向用户显示驱动程序的重新安装或驱动程序的更新版本的安装已成功完成。可替代地，监控单元116可以在检测到与驱动程序要求资源有关的问题之后自动地启动相关驱动程序的重新安装，或者安装这种驱动程序的更新版本，或者进行这种安装。在完成安装之后，可以向用户显示例如重新安装或更新版本的安装已成功完成。

作为另一种可能的对策，可以规定监控单元116在检测到异常工作的驱动程序之后启动主机107的重启。以这种方式，预留的资源被释放，从而防止意外的系统崩溃。

在另外的可能对策中，在检测到至少一个驱动程序对资源的异常要求时，可以自动地执行存储器转储，在这种情况下，完全或部分节省存储器。这样的存储器转储对于分析出了什么问题以及对于恢复否则会被丢失的信息都是有用的。

与至少一个驱动程序过度要求资源有关的问题尤其可能导致在执行系统扫描期间崩溃，尤其是执行系统扫描期间，可以寻址或安装用于所有现场总线组件的驱动程序。当单个驱动程序在使用后不释放资源时，可能导致操作系统期间的系统扫描期间崩的溃。这尤其适用于(但不仅限于)具有大量现场总线组件的大型现场总线系统。为了避免这样的系统崩溃，监控单元116可以被设计为建议用户将系统扫描分成几个较小的子扫描。作为对此的替代，监控单元116可以被设计为自动将扫描分成多个连续执行的局部扫描。