EP3622403A2 - Procédé pour le contrôle automatisé assisté par ordinateur de descriptions - Google Patents

Procédé pour le contrôle automatisé assisté par ordinateur de descriptions

Info

Publication number
EP3622403A2
EP3622403A2 EP18726317.3A EP18726317A EP3622403A2 EP 3622403 A2 EP3622403 A2 EP 3622403A2 EP 18726317 A EP18726317 A EP 18726317A EP 3622403 A2 EP3622403 A2 EP 3622403A2
Authority
EP
European Patent Office
Prior art keywords
interface
description
signal
functional description
test comprises
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP18726317.3A
Other languages
German (de)
English (en)
Inventor
Gerhard Schilling
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Publication of EP3622403A2 publication Critical patent/EP3622403A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318307—Generation of test inputs, e.g. test vectors, patterns or sequences computer-aided, e.g. automatic test program generator [ATPG], program translations, test program debugging
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318314—Tools, e.g. program interfaces, test suite, test bench, simulation hardware, test compiler, test program languages
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318342—Generation of test inputs, e.g. test vectors, patterns or sequences by preliminary fault modelling, e.g. analysis, simulation
    • G01R31/318357—Simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/261—Functional testing by simulating additional hardware, e.g. fault simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs

Definitions

  • the invention relates to a method for computer-assisted, automated checking of at least one request and for generating test data.
  • a "requirement” is here and below a description of a fundamentally arbitrary, technical process, which may be an electrical or electronic circuit, a hydraulic or pneumatic device, a mechanical device, a production process, a This list is only to be understood as illustrative and not conclusive: in particular, the above examples may also be mixed or combined in any desired manner Specified target system in all its functionality This requirement has at least one additional requirement
  • each of the requests is stored in at least one database and has at least an interface description and a functional description.
  • the invention has for its object to provide a method of the type mentioned, which generates higher quality requirements and recognizes incompleteness or inconsistencies as early as possible.
  • At least one request is stored in a database.
  • a database is a collection of data blocks that are stored in one or more files and that are set up for random access. This requirement has at least one further requirement as a subcomponent, wherein this subcomponent is to be treated basically in the same way as the main component. However, it is not mandatory to specify all specified ones
  • Each request has at least one interface description for at least one input and / or output signal and at least one functional description in a formalized form.
  • the interface description includes all details concerning the respective interface and the signal which is received and / or sent via this interface. These may be, for example: data width, value range, protocol, assigned physical value, sampling frequency, port assignment,
  • Interface description and / or the functional description During the completeness check of the interface description, it can be checked in particular whether all required information is contained in the interface description. These basically depend on the type of signal specified. So are purely binary signals much lower Definition requirements provided as serial or parallel transmitted data. If information is transmitted serially, for example, the application of the respective protocol is of crucial importance. With pure state information, the signal directly reflects an external system state, so that no protocol information is needed here. In the consistency check of the interface description, mutual dependencies are taken into account. If, for example, a signal is marked as a serial data stream in the interface description without specifying a corresponding protocol, this inconsistency can be detected and output as a warning or error.
  • information such as sampling rate, latency, and the required response time to a particular trigger event may be considered. It is also considered to check if the specified real-time requirements are consistent with each other.
  • An inconsistency arises, for example, from the fact that the reaction time of an interface description of an output signal is shorter than the sum of the associated sampling and processing times. Similarly, an inconsistency could be found by violating the sampling theorem. This applies to both input and output signals. If the sample rate is less than half the signal period, then a proper one
  • Interface descriptions If information about a signal is needed anywhere in the request, it can only come from the associated interface description. This one
  • the test includes the
  • Interface description Checking whether certain information is stored, for example, whether the interface is to be initialized, filtered or checked. Often, complex signal conditioning is required, which is done by specialized devices such as analog-to-digital converters, frequency counters, or other components. These components sometimes require initialization before the first value for the signal can be determined. For other interfaces, such as pure
  • Digital interfaces on the other hand, often do not require initialization. Depending on the signal quality, it may also be necessary to filter the signal associated with the interface to eliminate glitches or increase signal accuracy. It is useful to check whether relevant information is contained in the interface description, so that in the absence of this information, a corresponding warning is issued. In addition, it may be necessary to check a signal associated with the interface, for example to determine its consistency or quality. The presence of this information is also expediently checked in order to prevent Signals of poor quality or even irregular signals are fed to further processing.
  • the method according to the invention checks whether a corresponding method is stored or corresponding parameters, for example the number of required averagings, for filtering the measured value are stored.
  • the method according to the invention therefore checks whether a corresponding scope is defined.
  • it is intended to store not only the validity range but also intermediate values, in particular limit values of the signal in the interface description. These limit values can then be used, for example, in the functional description for comparison with the signal. It is however, it is not appropriate to check these limits for the completeness of the interface description, as a check based on objective criteria will fail. For such applications, it is more expedient to check the functional description such that only parameters from interface descriptions are used as comparison parameters. This results in a consistent use of the limits.
  • the signals obtained from interfaces must be stored in appropriate variables.
  • the functional description can then refer to these variables, as long as it is ensured that no loss of information occurs due to the storage of the signals in the variable.
  • the check comprises a comparison of the data width or the sign of the interface description with the associated variable. If this comparison comes to the result that information is lost when the signal is stored in the variable because, for example, the data width is too small or a possible negative sign is lost, a corresponding warning is generated.
  • the inventive method generates a corresponding warning.
  • This warning indicates to the developer that he either forgot a signal in the functional description or should delete this signal from the interface description or mark it as "reserved.”
  • this measure prevents the developer, for reasons of convenience, simply basically in the interface description of his request.
  • the developer avoids the need to first think about the necessary signals before creating the functional description, and the method according to the invention then acknowledges this procedure with a corresponding one Number of warnings, so that the developer forcibly a clean
  • output signals are inconsistent because different components of the request require different values for the output signal. For example, if one component sets a particular output signal to one, if one input signal A is active and another component sets the same output to zero when an input signal B is inactive, then there may well be conflicting conditions for the output signal, especially if the input signal A is active and the input signal B inactive is. Such errors are very difficult to find in the final target system and therefore cause a considerable lengthening of development time. It is therefore expedient to check the uniqueness of the output signals or output signal changes already in the functional description and to acknowledge cases such as those mentioned above with a corresponding warning.
  • a recursive algorithm that does not affect states such as fast analog-to-digital conversion, is not affected.
  • it is advantageous for the method according to the invention to check state change conditions as to whether values are used therein which are not stored in the interface description This forces the developer to store all the comparison values that it needs for its functional description in the interface description, where it can then be checked for consistency throughout the requirement.
  • Interface descriptions then generate a corresponding warning. It may happen, for example, that in addition to a completely processed signal, a signal raw form, for example the unfiltered signal, should also be stored. If there is an unexpected accident, then the temporal course of the raw signal can be read from this memory to find clues for an early detection of the accident. This information is of considerable importance for the further development of the target system, in particular in the case of security-relevant components such as aircraft or Power plant components. However, in order to feed the raw signal to a datalogger, it must be available to the Datalogger component. This can most easily be done by putting it in the
  • modes in which the target system to be created should each work differently.
  • These modes may be, for example: normal operating mode, undervoltage mode, defective sensor mode, defective actuator mode, insufficient memory space mode, etc.
  • modes for different embodiments of the requirement For example, be defined for different application models.
  • a specific component for a motor vehicle may have different modes for different motor vehicle models, so that the adaptation to a specific motor vehicle model can take place by a simple choice of the mode.
  • the different modes can also be used in combination. For example, two operating voltage modes, two sensor state modes, two actuator state modes, and four model modes can be used. This will give you 32 different modes. In reality, the modes can become much more complex, which significantly increases their accumulated number.
  • the invention also relates to a method for computer-assisted, automatic generation of test data for a target system which is to fulfill a requirement.
  • a plurality of test data is generated between the defined limits of the validity range of the individual signals in order to test the generated target system.
  • it is ensured that - assuming attention is paid to warnings - all threshold values for comparison with signals are stored in the interface descriptions.
  • all limits where the behavior of the target system changes in any way are uniquely determined by values specified in the interface descriptions. This is exploited in the inventive method for automatically generating test data in that the interface descriptions of all input signals are analyzed, all in the
  • Interface description entered values each Input signals are sorted. Between adjacent values of this sorted value series, the basic behavior of the target system does not change. Therefore, it is sufficient to generate a test value between these entered values and to output these values in different permutations as test data. This produces considerably less test data, it being ensured that each query condition of the signals in the test data is realized.
  • the test of the target system is not only faster, but also safer.
  • the method according to the invention is preferably used for requirements which serve to control and / or regulate at least one technical process. There are relatively high demands on the security of the target system to make, so the inventive method. particularly advantageous in this area.
  • the target system software is implemented, which runs on at least one controller, which also has memory and interfaces in addition to the central processing unit.
  • the target system software which runs on at least one controller, which also has memory and interfaces in addition to the central processing unit.
  • this area which is also referred to as “embeded system”, particularly high demands on software security, since interference with the software from the outside is usually not possible.
  • FIG. 1 shows a method for testing the
  • Figure 2 shows a method for testing the functional
  • FIG. 3 shows a method for realizing a state function
  • FIG. 5 shows the requirement according to FIG. 4
  • FIG. 1 shows an algorithm for checking the interface description for completeness. It is assumed that the developer has been provided with a template for creating an interface description in a database in which corresponding fields are to be filled in. The algorithm according to FIG. 1 checks those in the database stored interface descriptions in the following way:
  • a count variable n is initialized to the value 0.
  • step 3 a query is made as to whether a value is entered in the database for the interface description n in the field m. In addition, in step 3 it is queried whether the entered value in the database is also consistent with the remaining values of the interface description n. If at least one of the named tests fails, the query branches to branch 3F according to step 3. In this case, a corresponding warning is generated and output in step 4. If the tests according to step 3 do not find any objections, the branch 3T is used, which suppresses the output of the warning in step 4.
  • step 5 the count variable m is incremented to thereby address the next field within the interface description n.
  • step 6 it is queried whether the count variable m is still within permissible and predefined limit values. If this is the case, the branch 6T is branched, so that the program flow continues with step 3. However, if the count variable m is within the permissible range, branching is made to branch 6F and the following step 7 is executed.
  • step 7 the count variable n is incremented so as to address the next edit job description.
  • step 8 it is queried whether the count variable n is still within permissible and predefined limit values. If this is the case, the branch 8T is branched, so that the program flow is continued with step 2. However, if the count variable m is within the allowable range, branching is made to branch 8F and the following step is executed.
  • FIG. 2 shows an algorithm for checking the functional description. It is assumed that the functional description is stored in the form of a state machine in the above-mentioned database.
  • step 10 the function State (init) is called. This function puts a virtual
  • State machine in that state in which the state machine, for example, comes immediately after a reset. So this is the initial state of the state machine.
  • this function performs various checks, which are explained below.
  • step 11 a count variable n is initialized to zero. It is assumed that the individual states of the state machine in the database can be retrieved via the counting variable n initiated.
  • step 12 it is checked whether the checked flag is set in the state n. If this is not the case, the query branches to branch 12F according to step 12 and generates a corresponding warning in step 13, which is output. If the checked-flag was set, however, the query branches to branch 12T according to step 12 and suppresses the output of the warning by bypassing step 13. In step 14, the count variable n is incremented to thereby call the next succeeding state.
  • step 15 it is now checked whether the count variable n is within permissible limits or whether n references a state that no longer exists. If the count variable n is allowed, the query branches to the branch 15T according to step 15, so that the program flow branches to step 12. However, if the count variable n is invalid, the check is completed.
  • FIG. 3 shows the algorithm for the state function according to step 12. It goes without saying that the step 10 is to be formed in the same way.
  • a count variable m is initialized to the value 0.
  • This counter variable m references a corresponding state change condition for the respective, selected state, including a reference to the respective subsequent state.
  • a query is made as to whether a checked flag of the selected state is set. In this case, the program flow continues in branch 21T. However, if the checked-flag is not set, branch 21F continues. It should be noted that the checked-flag of each state is reset at the beginning of the described algorithm. Setting this checked-flag indicates that this condition has already been checked and Therefore, a further test can be omitted. In this way, endless loops are avoided. In addition, the efficiency of the algorithm is significantly increased in this way, since double and multiple checks of the same state are reliably excluded.
  • step 22 is executed, in which the checked-flag is set. This indicates that the current status has now been checked and a re-examination must be ruled out.
  • step 23 one or more queries about the state are made, which relate in particular to the completeness and consistency.
  • the branch 28F is branched and in step 24 a corresponding warning is issued. Otherwise, step 24 is suppressed by selecting the branch 24T.
  • step 25 a pointer of the transition condition with the index m is read out and in step 26 the function State is called with the pointer thus determined as a parameter. This results in a recursive call of the function State, which ensures that all possible states and state transitions are taken into account.
  • step 27 the count variable m is incremented to check the next transition condition.
  • step 28 it is queried whether the count variable m is still within permitted limits. If this is the case, branching takes place into branch 28T, so that step 21 is then carried out again. However, if the count variable m is in an invalid state, the branch 28F is branched and the query of step 29 is executed. In this query according to step 29, it is checked whether the count variable m has reached a value> 1. If so, the state function is terminated by selecting branch 29T. Otherwise, the branch 29F is selected and the warning is generated in step 30 that no subsequent state can be reached.
  • the execution of this algorithm is relatively complex due to the recursive call of the function State, but otherwise very difficult to realize.
  • the function State starts with the initial state according to step 10 and checks it according to the specified criteria. In the event that the condition has already been checked, all checks, including the calls of subsequent statuses, are suppressed.
  • the recursive algorithm first goes through the states in the order of the first transition condition in each state until either no subsequent state can be found or a state is called that has already been tested. Subsequently, the last selected transition condition of the state machine is changed to the transition condition specified next in the database and the algorithm is executed in the same way. Accordingly, the individual transitional conditions of Initialization state usually processed last.
  • FIG. 4 shows a request for a radio device in the black box representation.
  • the individual interfaces that ensure the connection of the device to the outside are specified, but the internal process remains largely unspecified.
  • the request 100 has a black box 101, input interfaces 102, output interfaces 103 as well as interference 104.
  • the processing of the incoming signals from the input interfaces 102 to generate the signals of the output interfaces 103 are reserved for the unspecified black box 101.
  • the input interfaces 102 have a
  • the input interface 102 includes an antenna port 115 through which electromagnetic waves can be received.
  • the output interface 103 comprises a loudspeaker 120 and light-emitting diodes 121 for function control. At potential interference 104 are
  • Output interfaces 103 the respective signals must be fully described in order to pass an integrity check according to the invention.
  • voltage level definitions and a maximum are usually sufficient
  • antenna input 115 In addition to transmission protocols and
  • Modulation modes are specified to make the target system functionally reliable.
  • FIG. 5 shows the requirement according to FIG. 4 with the subcomponents contained therein.
  • a functional description of the black box 101 according to FIG. 4 is inserted.
  • This functional description includes various subcomponents 130, which in turn exchange signals. Accordingly, the individual subcomponents 130 again require interface descriptions.
  • Various subcomponents 130 use external interfaces of requirement 100. Since these are already completely defined, there is no need for any further definitions.
  • subcomponents 130 also exchange signals with each other.
  • the subcomponents 130 have internal interfaces 131 which must again be specified accordingly.
  • Subcomponents 130 are again tested for completeness in the same way. However, it is possible to have individual subcomponents 130 of this
  • the requirement 100 according to FIG. 5 includes in the functional description a tuner 140, an amplifier 141, a loudspeaker 142, an LED driver 143 and a power supply 144.
  • the tuner 140 is connected to the antenna terminal 115 and the frequency band selector 112. In addition, it is to be expected that a fault feed 104 occurs in the form of electromagnetic waves.
  • the tuner 140 generates a low-frequency signal 150, to which a corresponding interface description at sub-component level create is.
  • the amplifier 141 receives this low-frequency signal 150, so that for the amplifier 141 in this regard no own
  • Interface description is required. Rather, reference is made to the interface description of the tuner 140. The completeness check of the interface descriptions ensures that the interface descriptions of the subcomponents are inherently consistent and not inadvertently different for the same signal
  • the amplifier 141 is connected to the speaker 142. For this purpose, the amplifier 141 generates an amplified signal 151 which is used for
  • the LED driver 143 is in communication with the tuner 140, the amplifier 141 and the power supply 144. Also in this regard are appropriate
  • the completeness check according to the invention ensures that potential sources of error in the development of the corresponding target system are detected early and the target system as a whole is consistently defined in itself. This reduces errors in the target system so that its technical functionality becomes more reliable.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)
  • Processing Or Creating Images (AREA)

Abstract

Cette invention concerne un procédé pour réaliser le contrôle automatisé assisté par ordinateur de descriptions, celles-ci étant stockées dans une base de données. D'une part, au moins une description d'interface et d'autre part, au moins une description fonctionnelle sont enregistrées. La description comporte au moins un sous-composant. Le contrôle inclut une vérification, assistée par ordinateur, de l'intégralité et/ou de la cohérence de la description d'interface et/ou de la description fonctionnelle. La vérification englobe les sous-composants.
EP18726317.3A 2017-05-08 2018-05-08 Procédé pour le contrôle automatisé assisté par ordinateur de descriptions Withdrawn EP3622403A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102017004348.5A DE102017004348A1 (de) 2017-05-08 2017-05-08 Verfahren zur Computer gestützten, automatisierten Überprüfung von Software-Anforderungen
PCT/EP2018/000246 WO2018206146A2 (fr) 2017-05-08 2018-05-08 Procédé pour le contrôle automatisé assisté par ordinateur de descriptions

Publications (1)

Publication Number Publication Date
EP3622403A2 true EP3622403A2 (fr) 2020-03-18

Family

ID=62222572

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18726317.3A Withdrawn EP3622403A2 (fr) 2017-05-08 2018-05-08 Procédé pour le contrôle automatisé assisté par ordinateur de descriptions

Country Status (6)

Country Link
US (1) US20200159980A1 (fr)
EP (1) EP3622403A2 (fr)
CN (1) CN110799951A (fr)
CA (1) CA3062465A1 (fr)
DE (1) DE102017004348A1 (fr)
WO (1) WO2018206146A2 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112286041B (zh) * 2020-09-09 2023-02-03 许继集团有限公司 一种电气设备冗余监控装置切换方法及切换控制系统
CN113392022B (zh) * 2021-06-30 2024-05-31 中国农业银行股份有限公司 测试需求分析方法、设备、计算机可读介质和程序产品
DE102022000208A1 (de) 2022-01-20 2023-07-20 GS Licence Pool UG (haftungsbeschränkt) Verfahren zur Computer gestützten Prüfung einer Anforderungsspezifikation eines technischen Prozesses

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10131438B4 (de) * 2001-06-29 2005-06-02 Daimlerchrysler Ag Verfahren zur Entwicklung einer technischen Komponente
US7392492B2 (en) * 2005-09-30 2008-06-24 Rambus Inc. Multi-format consistency checking tool
US20090144695A1 (en) * 2007-11-30 2009-06-04 Vallieswaran Vairavan Method for ensuring consistency during software development
DE102008039380A1 (de) * 2008-08-22 2010-02-25 It-Designers Gmbh Prüfsystem
US9134976B1 (en) * 2010-12-13 2015-09-15 Reservoir Labs, Inc. Cross-format analysis of software systems
DE102012217743B4 (de) * 2012-09-28 2018-10-31 Siemens Ag Überprüfung einer Integrität von Eigenschaftsdaten eines Gerätes durch ein Prüfgerät
JP6045050B2 (ja) * 2013-03-19 2016-12-14 Ｎｅｃソリューションイノベータ株式会社 ユーザインタフェース一貫性チェック方法、装置およびプログラム
US9355206B2 (en) * 2014-01-09 2016-05-31 Cavium, Inc. System and method for automated functional coverage generation and management for IC design protocols

Also Published As

Publication number Publication date
CA3062465A1 (fr) 2019-11-05
DE102017004348A1 (de) 2018-11-08
US20200159980A1 (en) 2020-05-21
WO2018206146A3 (fr) 2019-01-24
WO2018206146A2 (fr) 2018-11-15
CN110799951A (zh) 2020-02-14

Similar Documents

Publication Publication Date Title
EP1950639B1 (fr) Procédé destiné au fonctionnement d'une installation de processus, installation de processus et produit de programme informatique
EP3622403A2 (fr) Procédé pour le contrôle automatisé assisté par ordinateur de descriptions
EP2707999B1 (fr) Système de traitement de signaux et procédé de traitement de signaux dans un n ud de bus
DE112020004019T5 (de) Daisy-chain-modus-eingangssequenz
WO2005001690A2 (fr) Procede permettant de surveiller l'execution d'un programme dans un micro-ordinateur
EP3709166A1 (fr) Procédé et système de manipulation sécurisée de signal pour l'essai des fonctionnalités de sécurité intégrées
DE102012016403B4 (de) Verfahren zur Parametrierung eines Feldgeräts und entsprechendes Feldgerät und System zur Parametrierung
EP3761166A1 (fr) Procédé de gestion d'un appareil de terrain et système d'automatisation
EP2433189B1 (fr) Procédé pour analyser des archives de messages et programme informatique correspondant pour générer un automate à états finis
DE102012016406A1 (de) Verfahren zur Parametrierung eines Feldgerätes und entsprechendes System zur Parametrierung
EP1649373A2 (fr) Procede et dispositif pour la surveillance d'un systeme reparti
EP3430771B1 (fr) Masquage de l'influence de commandes de bus de terrain non prises en charge
DE102016216728A1 (de) Fehlerdiagnose in einem Bordnetz
DE102020209228A1 (de) Verfahren zum Überwachen wenigstens einer Recheneinheit
WO2009135569A1 (fr) Procédé et dispositif permettant de corriger des informations transmises sous forme numérique
EP3779797A1 (fr) Procédé d'entretien anticipé assisté par ordinateur d'un système technique
DE29914463U1 (de) Projektierungseinheit für korrespondierende Diagnosedatensätze eines Systems mit Steuerungseinheit und Bedien- und/oder Beobachtungseinheit, und System mit Mitteln zum Versionsvergleich von zugeordneten Diagnosedatensätzen
EP2402832A1 (fr) Procédé et système d'affichage pour le calibrage d'affichages normalisés de grandeurs de processus
EP1491985B1 (fr) Méthode de génération de temps dans une unité de traitement de données
EP1868100A2 (fr) Procédé de diagnostic d'erreurs
DE2949806C2 (de) Digitales Ausfiltern von Störimpulsen
DE102016015755A1 (de) Verfahren zum Betrieb eines Watchdog umfassend eine Mustererkennung für wiederkehrende Lastsituationen mit einem zweistufigen Ergebnisspeicher
WO2024074331A1 (fr) Procédé et dispositif de support pour prendre en charge une optimisation de robustesse pour un système de traitement de données, et système de ci correspondant
DE102022212057A1 (de) Verfahren zur Analyse von funktionalen Pfaden für ein eingebettetes System, Vorrichtung zur Datenverarbeitung, Computerprogramm und computerlesbarer Datenträger
WO2023156060A1 (fr) Procédé de vérification automatique de spécifications de demande d'un processus technique

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20191204

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20211201