WO2007118642A2 - Procédé permettant de contrôler la conformité, l'interopérabilité et les performances de dispositifs aux normes bacnet - Google Patents

Procédé permettant de contrôler la conformité, l'interopérabilité et les performances de dispositifs aux normes bacnet Download PDF

Info

Publication number
WO2007118642A2
WO2007118642A2 PCT/EP2007/003188 EP2007003188W WO2007118642A2 WO 2007118642 A2 WO2007118642 A2 WO 2007118642A2 EP 2007003188 W EP2007003188 W EP 2007003188W WO 2007118642 A2 WO2007118642 A2 WO 2007118642A2
Authority
WO
WIPO (PCT)
Prior art keywords
test
bacnet
network
building automation
tested
Prior art date
Application number
PCT/EP2007/003188
Other languages
German (de)
English (en)
Other versions
WO2007118642A3 (fr
Inventor
Volker Pregizer
Frank Schubert
Original Assignee
Fraport Ag Frankfurt Airport Services Worldwide
MBS Gesellschaft für Entwicklung und Handel von Software und Investitionsgütern mbH
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 Fraport Ag Frankfurt Airport Services Worldwide, MBS Gesellschaft für Entwicklung und Handel von Software und Investitionsgütern mbH filed Critical Fraport Ag Frankfurt Airport Services Worldwide
Publication of WO2007118642A2 publication Critical patent/WO2007118642A2/fr
Publication of WO2007118642A3 publication Critical patent/WO2007118642A3/fr

Links

Classifications

    • 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
    • G06Q10/00—Administration; Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements

Definitions

  • the invention relates to a method for the evaluation of BACnet building automation devices according to the BACnet standard in conjunction with each other within real estate, especially in large properties such as airports and building complexes.
  • the method includes several aspects, each of which has its own significance, in particular a method for the automated testing of building automation devices for conformity to the BACnet standard taking into account user-specific requirements, a method for testing building automation devices according to the BACnet standard for interoperability and a method for testing building automation equipment in a network according to the BACnet standard on performance.
  • the invention also relates to a software program for carrying out the method for checking for conformity.
  • Building automation systems are devices, software and services for automatic control and regulation, monitoring and optimization as well as operation and management for the energy-efficient, economic and safe operation of technical building equipment.
  • a variety of different devices from different manufacturers can be networked together.
  • the use of the internationally standardized communication protocol BACnet (ANSI / ASHRAE 135-2004 or DIN EN ISO 16484-5) - hereafter referred to as "BACnet" - can be used as a communication standard for more competition among the Providers of GA facilities.
  • the BACnet standard defines a variety of services, objects,
  • the American Association BMA (BACnet Manufacturers Association, www.bacnetassociation.org) operates a test laboratory called BTL (BACnet Testing Laboratories).
  • BMA has been preparing test plans for some years, which allow tests to be carried out on the basis of the standard (ANSI / ASHRAE 135-2004 / BACnet or DIN EN ISO 16484-5) and has already carried out manual BACnet test series.
  • the inventive methods enable each operator to rationally test and approve BACnet devices for their respective properties and project-specific requirements.
  • the at least partial automation of the tests makes it possible to check devices from different manufacturers within a reasonable time frame at manageable costs. Only then will an efficient method for the extensive certification of BACnet components be created.
  • test method allows the application to projects of any size and different functional requirement and thus a test of the building automation devices of any number of manufacturers, taking into account the respective user-specific requirements.
  • the automated tool makes it possible for all properties with economically justifiable effort to verify the property-specific requirements taking account of the standard across all manufacturers. In doing so, user-specific requirements, which can be freely defined by the respective properties (especially in large properties such as airports and building complexes), can be taken into account.
  • this method allows property operators of a network with BACnet building automation systems from different manufacturers in a network network to use the BACnet communication protocol with the required depth in a manufacturer-neutral manner.
  • FIG. 1 shows schematically a flowchart for the automated test for conformity
  • FIG. 2 shows the message of a conformity checking program in the event of cancellation
  • FIG. 3 shows a possible user interface during a consistency test as part of the conformity check
  • FIG. 4 shows a window of a test software during the execution of the test plan in the context of the conformity check
  • FIG. 5 shows the schematic sequence of a server test within the scope of the conformity check
  • FIG. 6 shows the schematic sequence of a client test in the context of the conformity check
  • FIG. 7 schematizes the course of an interoperability test
  • the method according to the invention consists in an evaluation of the properties of building automation devices according to the criteria of BACnet conformity and their interoperability in combination within large properties.
  • the components of this procedure are a conformity test, which is carried out separately for each GA unit, and an interoperability test, which is carried out with two GA units in combination with each other, which have passed the conformity test.
  • the test results are documented and reported back to the manufacturer of the GA units.
  • a performance test is additionally performed in a network environment.
  • Figure 1 shows schematically a flowchart for the automated test on
  • Conformity based on a test software.
  • the conformity to the BACnet standard has to be checked. To keep the effort as low as possible, only the actually required functionalities are checked. For this, the operator of a property to be equipped with building automation equipment is provided with a test specifications ("GA specifications") containing the user-specific requirements, for example also the settings to be used according to BACnet standard.
  • GA specifications test specifications
  • test units under consideration of the GA specifications.
  • a test unit a single or a composite of several BACnet devices is understood, which was prepared according to the requirements (programming / parameterization).
  • the manufacturer provides a documentation of the operating steps as well as a device description in the standardized format "EPICS" (Electronic Protocol Implementation Conformance Statement document (EPICS, see ISO 9646)), which announces the degree of its BACnet implementation
  • EPICS fulfills the function of the PICS and PIXIT documents in electronic form in accordance with the ISO 9646 standard.
  • the user-specific requirements are first of all entered in a test database as a default.
  • the EPICS file provided by the manufacturer is read in as a template by a test software.
  • a syntactic examination is carried out.
  • the file is rejected and the import is terminated, otherwise the data is stored in the test database.
  • FIG. 2 shows the message of the program in the event of an abort.
  • the manufacturer's specifications in the EPICS document are automatically compared with the user-specific requirements specified in the test database. Unsupported functions, objects and properties including their BACnet formats of the test unit are evaluated as negative test results and stored automatically in the database.
  • EPICS Consistency Check In the following automated test step, a so-called EPICS consistency test according to the ANSI / ASHRAE 135.1 standard is carried out.
  • the test steps for the EPICS Consistency Check are defined in 135.1 and stipulate, among other things, that a check must be carried out in such a way that all the functionalities described in EPICS are actually present in the test unit. This is done by reading out the functionalities from the test unit and then performing a software-related comparison on set and actual state of the functions.
  • FIG. 3 shows the possible user interface during the consistency test.
  • test step based on the BACnet functions implemented in the test unit, automatic generation of a test plan in the test software will result from the BACnet services and BACnet objects to be tested, including the user-specific optional properties and the application-specific required read / write access .
  • the individual test steps described in the standards for example ISO 9646
  • the positive and negative test results of the individual test steps are automatically checked and documented.
  • FIG. 4 shows the window of the test software during the execution of the test plan.
  • the test database contains script files for carrying out the respective tests.
  • the test scripts are preferably developed using the freely accessible scripting language PYTHON.
  • test results are stored in a database and can be exported to Office applications for evaluation. Individual results can be overwritten manually, but the original result is retained. This serves to evaluate a fact that is not clear in the standard, which must be examined further, as positive at first. In individual cases, however, a positive test result can also be negatively evaluated manually if e.g. after proper execution of the single test the device is restarted or problems with the device have been noticed, although the actual test result was positive.
  • a manufacturer submits a test unit, for example, which, as specified in EPICS, supports the BACnet function DM-BR-B (Device Management Backup / Restore as provider).
  • DM-BR-B Device Management Backup / Restore as provider.
  • the first test step would thus be fulfilled for this individual function (requirement by the operator of the property, provision in the test unit based on the manufacturer's information).
  • test step one is thus to be considered negative.
  • test steps include both positive tests, i. the test software sends a valid telegram with correct data content and expects the test object to receive a valid result, which can either be automated via the BACnet protocol, e.g. by a list of valid return values or by e.g. Reading a value e.g. on an operating display (current room temperature, etc.) is verified by the operator of the test software.
  • test unit from a manufacturer fully complies with all the requirements of the GA specifications, standards 135.1 and 16484-5 and the accompanying extensions.
  • Tests serve. These test steps verify compliance with the Area of the BIBB DS-RP-B and serve here as an example for all BACnet BIBBs.
  • a check is made as to whether the device under test supplies a valid error code when attempting to read from an element (property) specifying an array index, where the referenced property is not an array.
  • a check is made as to whether the device under test supplies a valid error code when attempting to read from an array specifying an array index outside the range of the array.
  • test cases specified in 135.1 as well as all test procedures and result documentation are carried out as far as possible automatically within the test software.
  • manual tests are also performed during the tests.
  • the manual tests refer to the evaluation of read (read by the operator) values on a display, mainly in the area of the BACnet client functionality. These are also marked and specified as such in 135.1.
  • the evaluation is made as to whether a test object has successfully passed the correspondingly specified individual test.
  • a single step can only be considered successful if the result set is in the range of the 135.1 specified results, with manual readings possibly in a specified value range.
  • the method is carried out by means of a test software program for which a standard IBM compatible PC (at least 2 GHz, 512 MB
  • RAM RAM
  • Microsoft Windows 2000 or XP Professional operating system a Microsoft Windows 2000 or XP Professional operating system
  • corresponding hardware or software drivers e.g. RS-232, network card or TCP / IP required.
  • the test software works as a BACnet client and as a BACnet server and can test both BACnet server devices and client devices.
  • Script processing is configurable based on ASCII files (Python scripts), a separate script management of the test procedures is possible.
  • Test generator works on the basis of predefined scenarios with a
  • test software works as a BACnet client, it will largely automatically query the BACnet server to be tested in accordance with the test specifications of standard 135.1 and the user-specific requirements and record the results. For certain interventions (eg switching operations on the device), the execution is stopped and the message box is used to wait for the test steps to be processed manually. In this case it is possible to enter a free comment text by the operator.
  • the schematic sequence of such a server test is shown in FIG. 5. If the test environment works as a BACnet server that provides objects for the BACnet client to be tested, checking for correct client behavior requires manual operator input (eg "Value: 27.2 read") possible.
  • a new test session optionally starts with the reading of an EPICS
  • the EPICS only contains the properties available in the device, but a customer / operator of a property may want a device that must support the optional properties in order to be considered successfully tested (implementation of customer-specific requirements).
  • the database provides a reference to individual tests in protocol reviews 135-2001 and 135-2004. These are stored in the database with an indication of the wheel and file name on an external directory / file. Future BACnet revisions can also be implemented in this way.
  • the individual tests of the test plan are created as a list. If a test contains one or more dependencies, the dependent tests are also assigned automatically. If the selected tests are not to be applied to certain objects / properties, these objects or properties can be deactivated in the operating software (GUI).
  • GUI operating software
  • the GUI starts generation of the script-based test plan, i.
  • the GUI generates the test plan to be executed later using the device information and the associated tests as a Python file.
  • This method has been specified to logically separate the data to be tested (objects / properties) from the actual test functions (e.g., WritePropertyMultipleTest).
  • the total amount of tests contained in the test plan is determined and assigned to the value 100% for later percentage display.
  • the interpreter is called with
  • TCP port + IP Communication with the operating software to be used TCP port + IP is read from the configuration data of the interface and appended as another command line argument to the call.
  • the operating software now expects messages from the Python interpreter about the
  • the result values of the individual tests are also transmitted with a separate message and are used in the
  • the results of the actual test plan are kept separated with the time stamp of the test execution.
  • test environment For client testing, it is necessary for the test environment to be a BACnet
  • Server object provides. This is also defined in the operating software. For this purpose objects, properties and values of the simulation server are defined. These properties can be saved as templates for later recall. After starting the test plan, therefore, the server device is first generated based on the defined configuration. The schematic sequence of such a client test is shown in FIG. 6.
  • Python interface is an essential part of the reproducibility and serves as a proof of performed tests.
  • An accredited test laboratory is required to provide evidence of tests performed. Since the operating software creates these tests in readable form (py file), the evidence is given.
  • Telegrams as well as implementation of the TSM (Transaction State Machine) with the possibility to transfer all telegrams instead of answering these directly to the calling program parts (Python) for processing.
  • TSM Transaction State Machine
  • This interface is used to implement a progress bar in the GUI and to synchronize between GUI and Python. Only messages from Python are sent to the GUI.
  • the value is stored in the DB together with the number of the test step.
  • the DataDank contains the references to the external py files of the tests as well as the test projects, device information, etc.
  • the required data model results from the previous descriptions of the test procedure of this specification and is specified as a DB model.
  • test plans tests, test steps can be referenced later (ODBC / database) and the results in the form of printouts, processing in tables, etc. further processed.
  • test step contains functions that are not supported by the BACnet stack, eg VT- Tests), as well as negative return values, eg: Timeout when accessing the device (in this case, the interface may offer to cancel the further execution of the test plan) and Python not installed.
  • a percentage indication with a cancel option is displayed. With each start message, the percentage is increased by the percentage step and the percentage is updated.
  • a test consists of a script coded in Python, which implements the individual test, for example, using the chapters in 135.1. Proprietary objects and proprietary properties require (if possible through the stack) proprietary scripts, ie they may need to be specially programmed. These tests should be added to the database and also deleted again (reference to py file). The conformity check is therefore largely automated and limited to the functionality required by the operator / customer.
  • the devices or test units can be tested for interoperability.
  • test cases For the evaluation of interoperability, test cases have been developed that can be used to assess whether and to what extent several BACnet devices work together correctly. Based on the test cases, all devices or
  • Test units in the network network checked for correct interaction.
  • Test steps are monitored and evaluated using test tools (network analyzer, etc.).
  • the log files recorded during the execution of the tests using the test tools are archived by the test personnel and, if necessary, documented. These log files allow a later assessment of possible problem cases and serve as proof of the test tools.
  • the interoperability tests therefore check and document the reconciliation between different devices in order to achieve optimal interaction.
  • the BACnet standard only describes the communication in the ISO / OSI model layers 1 to 7, but not the implementation of the respective BACnet application.
  • a check for a different processing of the values in devices from different manufacturers e.g. the processing of decimal places, etc.
  • all devices to be examined must first be integrated into a common network network, i. There is a physical and communicative connection from every device to every other device. In each case, the combination of the application implementations of two devices in this network is examined.
  • a device If a device provides a B function (e.g., ReadProperty-B), it must
  • Each single function supported by both devices is a single interoperability testing step.
  • the provided value or the provided BACnet function (eg data backup) is read from the provider and documented.
  • the requestor reads this value or executes the provided function at the provider. If the value read out corresponds to the previously determined value Result or the function was successfully completed by both sides, this single step is considered to have been successfully fulfilled.
  • this single step should be considered as unsuccessful.
  • the devices are devices of different manufacturers, then in a following step it can be checked and defined which adjustments have to be made in the implementation in order to achieve an interoperability.
  • one of the two manufacturers could increase timing or resource parameters to accommodate the characteristics of the other communication partner.
  • the interoperability tests provide a basis for decision making for possible extensions of the device applications.
  • FIG. 7 schematically shows the course of the interoperability tests.
  • the areas in which the devices fit together, ie BIBBs, network types, etc., must be determined, this is determined using the PICS or EPICS. From this a test plan is generated. For each test step, an evaluation is carried out successfully and not successfully and documented.
  • the tests to be performed start with simple functions such as reading or writing values (data sharing) to complex functions such as
  • RemoteDeviceManagement for example, restarting a device
  • backup / restore Functions such as RemoteDeviceManagement (for example, restarting a device) or backup / restore.
  • Interoperability tests can not be automated, but are done manually using a connected network analyzer.
  • a BACnet control system or the client part of such and, as a server device, the server part of a BACnet automation station will be referred to as client device. Since the interoperability tests depend very much on the supported functions of the respective devices, the following questions should be answered in each individual test session: Device Binding Can the client device find its communication partner using the Who-Is and Who-Has functions and determine its properties? Attention is paid to special features such as static address binding in the run-up to the respective test session and the devices are configured to the respective test conditions by the cooperation of the manufacturers. The test is then successfully passed, if all the properties of all
  • Interoperability ranges (IOB) of both devices could be successfully read out.
  • Data sharing (configuration and operation)
  • Client devices may e.g. based on
  • Protocol_Revision detect which BACnet version of the
  • Communication partner is supported. The test is successfully passed if the client device is able to read the properties of all objects of its communication partner completely successfully and, if implemented, can set its communication according to the BACnet protocol revision.
  • Alarm / COV Configuration Can the client device affect alarms and COV in the server device and log in for alarms and COV?
  • Alarm / COV Reception Can the client device receive alarms and COV from the server device? Is there a receipt acknowledgment for confirmed services?
  • Alarm list Can the client device request an alarm summary (alarm summary, event information) from the server device?
  • Reading out the schedule configuration Can the client device read out the schedules of a schedule object of a server device?
  • Schedule configuration Can the client device influence Schedule objects?
  • Schedule data types Are both data types of the Schedule object (at least Analog, Binary, MultiState) supported by both devices?
  • Restart tests Can the client device restart the server device (ReinitializeDevice)? Are both types of restart supported (coldstart / warmstart)? Are the optional passwords supported?
  • Time Synchronization Tests Can the client device send TimeSynchronization and UTCTimeSynchronization messages? Can the server device receive and enforce these messages?
  • one BACnet router is another
  • Halfrouter Tests Can the client device initiate and terminate a PTP connection through a halfrouter (EstablishConnectionToNetwork and DisconnectConnectionToNetwork)?
  • the offered BACnet components are tested and documented both in the test laboratory and in the user-specific IT network in terms of data throughput, response times and network bandwidth measured between their subsequent installation location on the network route used to the specified communication partners.
  • the aim of the performance investigations is to examine and document network properties of the IT infrastructure in relation to the reaction times of the devices as well as to check for possible influence on the communication of a BACnet network. Test cases are developed that allow conclusions to be drawn regarding the expected performance of the devices in terms of network bandwidth, response times and overall throughput.
  • Each individual device is first subjected to an examination of reaction times without consideration of the entire network network.
  • the network reaction time between the planned installation location of the device and the location of the communication partners is determined.
  • the test units are connected at the network site at the installation site via the network path used to the specified communication partners and the performance is measured. All test steps are documented and archived for later use and assessment.
  • BACnet-ping BACnet-ping
  • UDP protocol, used port numbers, etc. protocol-specific properties required for BACnet
  • the defined in the respective test step amount of BACnet telegrams is sent with a defined data content from a defined point of the network to another defined point of the network over a defined section of the network.
  • the time required to transport this amount of data is logged at both access points to the network and documented in the checklist.
  • Figure 8 illustrates the performance test.
  • Performance examinations thus serve as a basis for deciding on the selection and specification of the BACnet devices to be used and for determining the network requirements.
  • Performance considerations in the network environment are basically divided into three areas: Performance analysis of the server devices, the client device and the network.
  • the goal is to determine the maximum time required for the communication of individual, comparable information between individual information points of a server device over the entire signal path ("worst-case view"), eg analog actual value, digital setpoint value, multi-level value, etc.
  • the term "entire signal path” is understood to mean the entire path from physical input or output to the end point of the communication (eg control station). Timing must therefore begin by triggering the desired action (e.g., actuating a switch or altering the measurement) and measuring the time to time the message arrives at the desired endpoint (e.g., at the building control center GLT).
  • the server device to be examined is configured with the maximum number of objects to be managed specified by the manufacturer. This is important for considering the maximum expected latency.
  • data points are selected for the determination from the overall configuration, of each data point type at least three pieces are consulted, in each case the first data point per data point type related to the configuration of the device, the last and any selected point within the data point range.
  • the selection is made on the basis of a data point list that must match the configured objects in the device.
  • Network introduced installation for testing purposes.
  • the structure of the total distance must take place over the longest possible route or the slowest communication path of a network (here are possibly dial-up connections in a network (additional connection setup phase), ping times in one
  • test execution slot has the greatest distance or slowest connection in the network relative to the desired endpoint (e.g., GLT).
  • the data points are triggered individually and the time taken for the end point is measured using two persons with a permanent speech connection (for example via telephone or radio, etc.).
  • One person triggers the data point, the second person triggers a stopwatch and stops it on arrival of the expected value change at the endpoint.
  • three times are counted down via the speech connection before triggering (synchronization of "transmitter” and "receiver”).
  • the same test is performed three times per data point and averaged. Latencies in the voice connection, etc. are ignored in this model.
  • the examination is carried out with one reference device each taking into account the maximum possible configuration.
  • the aim of the test is the simulation of a high utilization of the control technology (BACnet client) by high data transfer on the part of the BACnet server.
  • BACnet client control technology
  • BACnet simulation programs generate a permanent and predictable "telegram flood."
  • the aim of the measurement is to determine the reaction times of the control technology by connecting a defined number (eg 10-15 pieces) of BACnet servers in a small network be influenced by means of control parameters of the simulation server.
  • the values are visually compared with the currently simulated values of the servers. Expected is a "run-on" of the values in the display of the client, which increases with increasing network traffic and decreases with decreasing network traffic.When there is too much data traffic (no more amount to be processed by the device), telegrams can be expected no longer be answered and therefore must be repeated.A failure of a device or other misconduct of the device are also conceivable effects.
  • the visual control stopwatch
  • the simulation devices must for practical implementation of the test series in the control This requires the support of the BMS supplier.
  • the average load of the network (utilization) as well as the available bandwidth should be considered. Since ICMP is only very suitable as a network protocol for measuring a maximum time period for the transmission of a packet because routers can be configured so that certain protocols are transported prioritized, another form of verification is necessary. The check is therefore based on the UDP protocol used in BACnet / IP.
  • a test program (“UDP-ping") that can run on a PC sends a defined number of packets of the maximum possible message length of 1,476 bytes to a remote PC, each of which sends back a defined response telegram
  • the averaged time for all packets and telegrams divided by two gives the average delay time in a network.

Abstract

L'invention concerne un procédé permettant de contrôler automatiquement la conformité de dispositifs immotiques à la norme BACnet, un procédé permettant de contrôler l'interopérabilité desdits dispositifs en fonction de la norme BACnet, ainsi qu'un procédé permettant de contrôler les performances desdits dispositifs dans un réseau selon la norme BACnet.
PCT/EP2007/003188 2006-04-10 2007-04-10 Procédé permettant de contrôler la conformité, l'interopérabilité et les performances de dispositifs aux normes bacnet WO2007118642A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006016760.0 2006-04-10
DE102006016760A DE102006016760A1 (de) 2006-04-10 2006-04-10 Verfahren zur Prüfung von BacNet-Einrichtungen auf Konformität, Interoperabilität und Performance

Publications (2)

Publication Number Publication Date
WO2007118642A2 true WO2007118642A2 (fr) 2007-10-25
WO2007118642A3 WO2007118642A3 (fr) 2008-10-16

Family

ID=38536526

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/003188 WO2007118642A2 (fr) 2006-04-10 2007-04-10 Procédé permettant de contrôler la conformité, l'interopérabilité et les performances de dispositifs aux normes bacnet

Country Status (2)

Country Link
DE (1) DE102006016760A1 (fr)
WO (1) WO2007118642A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109412903A (zh) * 2018-12-30 2019-03-01 国网北京市电力公司 通信测试方法与装置
CN115102889A (zh) * 2022-07-26 2022-09-23 中国电力科学研究院有限公司 一种客户侧能源量测数据交换协议远程测试方法及系统

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0478175A1 (fr) * 1990-09-13 1992-04-01 Hewlett-Packard Company Analyseur de protocole
US5937165A (en) * 1996-09-10 1999-08-10 Ganymede Software, Inc Systems, methods and computer program products for applications traffic based communications network performance testing
EP1122913A2 (fr) * 2000-01-31 2001-08-08 Lucent Technologies Inc. Génération de suites d'essai pour l'interopérabilité des systémes de communication réactifs
WO2001061921A2 (fr) * 2000-02-14 2001-08-23 Teradyne, Inc. Outil d'analyse d'erreur reseau
EP1213876A1 (fr) * 2000-12-06 2002-06-12 Tektronix, Inc. Circuit pour tester un systéme de communication
US6625648B1 (en) * 2000-01-07 2003-09-23 Netiq Corporation Methods, systems and computer program products for network performance testing through active endpoint pair based testing and passive application monitoring
US20050007958A1 (en) * 2002-06-03 2005-01-13 Karl Auerbach Testing device
US6895440B1 (en) * 2000-05-25 2005-05-17 Cisco Technology, Inc. Network component performance testing
WO2005101740A1 (fr) * 2004-04-16 2005-10-27 Apparent Networks, Inc. Procede et appareil pour l'automatisation et l'echelonnage du controle et du diagnostic des performances de reseau ip bases sur le sondage actif

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0478175A1 (fr) * 1990-09-13 1992-04-01 Hewlett-Packard Company Analyseur de protocole
US5937165A (en) * 1996-09-10 1999-08-10 Ganymede Software, Inc Systems, methods and computer program products for applications traffic based communications network performance testing
US6625648B1 (en) * 2000-01-07 2003-09-23 Netiq Corporation Methods, systems and computer program products for network performance testing through active endpoint pair based testing and passive application monitoring
EP1122913A2 (fr) * 2000-01-31 2001-08-08 Lucent Technologies Inc. Génération de suites d'essai pour l'interopérabilité des systémes de communication réactifs
WO2001061921A2 (fr) * 2000-02-14 2001-08-23 Teradyne, Inc. Outil d'analyse d'erreur reseau
US6895440B1 (en) * 2000-05-25 2005-05-17 Cisco Technology, Inc. Network component performance testing
EP1213876A1 (fr) * 2000-12-06 2002-06-12 Tektronix, Inc. Circuit pour tester un systéme de communication
US20050007958A1 (en) * 2002-06-03 2005-01-13 Karl Auerbach Testing device
WO2005101740A1 (fr) * 2004-04-16 2005-10-27 Apparent Networks, Inc. Procede et appareil pour l'automatisation et l'echelonnage du controle et du diagnostic des performances de reseau ip bases sur le sondage actif

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Information technology - Open Systems Interconnection - Conformance testing methodology and framework. Part 1: General concepts" INTERNATIONAL STANDARD ISO/IEC, XX, XX, Bd. 9646-1, 15. Dezember 1994 (1994-12-15), Seite 55pp, XP009095055 *
"Systeme der Gebäudeautomation - Teil 5: Datenkommunikationsprotokoll" DIN EN ISO 16484-5, 2003, Seiten 423-425, XP002466884 Beuth Verlag GmbH, 10772 Berlin in der Anmeldung erwähnt *
ANON: "Method of Test for Conformance to BACnet" ANSI/ASHRAE STANDARD 135.1-2003, 31. Dezember 2003 (2003-12-31), Seiten 1-22, XP002489861 American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc., 1791 Tullie Circle, NE, Atlanta *
BASAPUR V K ET AL: "Conformance testing in the telecommunications industry" IEEE INTERNATIONAL CONFERENCE ON COMMUNICATIONS ICC '90 INCLUDING SUPERCOMM. TECHNICAL SESSIONS, 16-19 APRIL, ATLANTA, NEW YORK, NY, US, 16. April 1990 (1990-04-16), Seiten 1399-1403, XP010002698 *
UNKNOWN: "Durchsatz (Version vom 26.03.2006)" WIKIPEDIA, DEUTSCHSPRACHIG, [Online] 26. März 2006 (2006-03-26), XP002489862 Internet Gefunden im Internet: URL:http://de.wikipedia.org/w/index.php?title=Durchsatz&oldid=15048152> [gefunden am 2008-07-25] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109412903A (zh) * 2018-12-30 2019-03-01 国网北京市电力公司 通信测试方法与装置
CN115102889A (zh) * 2022-07-26 2022-09-23 中国电力科学研究院有限公司 一种客户侧能源量测数据交换协议远程测试方法及系统

Also Published As

Publication number Publication date
DE102006016760A1 (de) 2007-10-25
WO2007118642A3 (fr) 2008-10-16

Similar Documents

Publication Publication Date Title
DE69531689T2 (de) Verfahren zur uberwachung von telefon und/oder datennetzwerken insbesondere mobilen telefonnetzen
DE69637142T2 (de) Netzwerkverwaltung mit Erfassung von formatierten Abzugdaten aus einem Fernprozess
EP2158776A1 (fr) Procédé de test d'un appareil de téléphonie mobile
DE4426740C1 (de) Testverfahren sowie Konvertereinrichtung, Testeinrichtung und Testprogramm-Modul dafür
DE10151116A1 (de) Verfahren zur Inbetriebnahme eines Bedien- und Beobachtungssystems von Feldgeräten
DE102006032108A1 (de) System und Verfahren für eine Mehr-Ort-Testausführung
DE102006028309B4 (de) Mehrseitiges, gemeinschaftliches Verwenden von dynamischen Daten in einer drahtlosen Testumgebung
DE102004048666A1 (de) Erweiterbarer Netzwerkagent - Verfahren, System und Architektur
DE602004010403T2 (de) System zur prüfung eines funkgerätes
WO2003027916A2 (fr) Gestion de processus
WO2007118642A2 (fr) Procédé permettant de contrôler la conformité, l'interopérabilité et les performances de dispositifs aux normes bacnet
EP1286141B1 (fr) Dispositif programmable avec un instrument de mesure, méthode pour programmer ledit dispositif et logiciel pour la mise en oeuvre du procédé
DE10245641B4 (de) Verfahren zur Aktualisierung des lokalen Managementsystems in mindestens einem Netzelement eines Telekommunikationsnetzwerkes
DE102006028311A1 (de) Mehrseitige Synchronisation einer Ausführung in einer drahtlosen Testumgebung
DE10290696T5 (de) Verfahren und System zum drahtlosen Zugriff auf einen Computer eines Benutzers
EP2237590B1 (fr) Procédé et dispositif pour tester des terminaux fonctionnant dans des réseaux de communication et/ou programmes exécutés sur ces terminaux
EP3044667A1 (fr) Procédé pour vérifier des logiciels générés ainsi que dispositif de vérification pour la réalisation d'un tel procédé
DE10028870A1 (de) Elektronische Wagenprüfkarte
EP2002679A1 (fr) Saisie de donnees de mesure
WO2005018153A1 (fr) Dispositif d'analyse de messages et procede d'analyse
EP1913754A1 (fr) Dispositif et procédé pour la configuration de terminaux de télécommunication
Oemig HL7® FHIR®–Fast Healthcare Interoperability Resources: Eine Einführung.
DE10311697B4 (de) Verfahren zum Abbrechen von Management-Operationen in einem Managementnetz und Kommunikationssystem
DE102021125430A1 (de) Verfahren zur automatisierten Fehleridentifikation von Hardware/Software-Systemen
EP1397891A2 (fr) Procede et systeme pour gerer la configuration et l'etat d'un reseau

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07724129

Country of ref document: EP

Kind code of ref document: A2

122 Ep: pct application non-entry in european phase

Ref document number: 07724129

Country of ref document: EP

Kind code of ref document: A2