Methods for analyzing malfunctions of refrigeration systems and / or building technology systems, as well as analysis systems for analyzing malfunctions of a refrigeration system and / or a building technology system

Abstract

Method for analyzing faults in refrigeration systems (33) and / or building technology systems, comprising the steps of: - Receiving a fault message (M, M1, M2) from a refrigeration system (33) or a building technology system; - Determining one or more fault causes (U, U1, U2, U3, U4) associated with the received fault message (M, M1, M2) from a database (17); - For each of the determined fault causes (U, U1, U2, U3, U4): - Determining a fault cause probability (W1) associated with the respective fault cause (U, U1, U2, U3, U4); and - Determining one or more repair measures (R, R1, R2, R3, R4, R5) associated with the respective fault cause (U, U1, U2, U3, U4) from the database (17); - For each of the repair measures associated with the respective fault cause (U, U1, U2, U3, U4): (R, R1, R2, R3, R4, R5):- Determining a repair success probability (W2) assigned to the respective repair measure (R, R1, R2, R3, R4, R5);and- Outputting the identified causes of faults (U, U1, U2, U3, U4) together with the respective assigned repair measures (R, R1, R2, R3, R4, R5), wherein the causes of faults (U, U1, U2, U3, U4) are output in a fault cause sequence (S1) according to the identified fault cause probabilities (W1) and wherein the repair measures (R, R1, R2, R3, R4, R5) assigned to a respective fault cause (U, U1, U2, U3, U4) are output in a repair measure sequence (S1) according to the identified repair success probabilities (W2).;

Description

[0001] The invention relates to a method for analyzing malfunctions of refrigeration systems and / or building technology systems, as well as an analysis system for analyzing malfunctions of a refrigeration system and / or a building technology system.

[0002] Refrigeration systems can be used, for example, in supermarkets to cool food or other goods and comprise the refrigeration units and refrigeration consumers used in the supermarket. A refrigeration unit in such a system can be designed to supply one or more refrigeration consumers with the required cooling capacity. These consumers could be, for example, refrigerators or freezers in which the goods to be cooled are stored. Individual refrigeration units—which can also be called chillers—can, in turn, be grouped together to form a centrally controlled system, so that a refrigeration system can generally encompass all refrigeration units, all individual refrigeration units, and all refrigeration consumers at a given location, such as a supermarket.Furthermore, refrigeration systems can, in principle, include several different types of refrigeration units or refrigerated display cases, for example, to store and offer frozen goods for sale in freezers and goods requiring higher temperatures in refrigerated display cases. However, a refrigeration system can also be designed as a single refrigerated display case, such as a chest freezer or a refrigerator.

[0003] Furthermore, building services systems can be designed, for example, for air conditioning or ventilation of buildings and may include one or more air conditioning systems, heating systems, or ventilation systems. It may also be the case that several such systems are combined into a single building services system, or that individual systems, such as a single air conditioning unit, are installed in a building and function as a building services system.

[0004] Due to the variable application of such refrigeration and / or building technology systems, these systems can often be complex and configured in diverse ways. Different refrigeration and / or building technology systems may differ, for example, in the number of units combined into a system and / or the type or model of the equipment used, in order to achieve operation optimized for the respective requirements. However, this diverse composition of refrigeration and / or building technology systems presents the challenge that, in the event of a malfunction, precise knowledge of the specific system and experience in its repair and maintenance are required to resolve the issue efficiently.Repairs to such systems are usually carried out by external maintenance personnel. However, even experienced and well-trained maintenance personnel must first gain an overview of the specific system and the reported malfunction in order to carry out a repair. Therefore, troubleshooting such systems is usually associated with an undesirably high time expenditure. Furthermore, especially in the area of ​​refrigeration systems used to cool perishable goods, prolonged malfunctions can potentially lead to product loss and the associated financial damage.

[0005] Therefore, one object of the invention is to create a method and an analysis system that enables faster and more convenient troubleshooting of malfunctions in refrigeration systems and / or building technology systems.

[0006] This problem is solved by a method having the features of independent claim 1.

[0007] The process includes the following steps: - Receiving a fault message from a refrigeration system or a building technology system; - Determining one or more of the fault causes associated with the received fault message from a database; - for each of the identified causes of the malfunction: - Determining the probability of each fault cause being assigned to that cause; as well as - Determining one or more repair measures from the database that are associated with the respective cause of the malfunction; - for each of the repair measures assigned to the respective cause of the malfunction: - Determining the probability of repair success associated with each repair measure; and - Outputting the identified causes of malfunctions along with the respective assigned repair measures, whereby the causes of malfunctions are output in a sequence according to the identified probabilities of the causes of malfunctions, and whereby the repair measures assigned to a respective cause of malfunction are output in a sequence according to the identified probabilities of repair success.

[0008] Such a procedure makes it possible, in particular, to support the responsible maintenance personnel in fixing a malfunction in a refrigeration system and / or in a building technology system by making experience in fixing malfunctions available and usable in a technically sophisticated way by reading out a database.

[0009] In particular, by reading information stored in the database, potential causes of malfunctions underlying the received fault message or the malfunction it describes can first be identified. This database reading allows for the replication of empirical data regarding which causes of malfunctions are generally possible when a specific fault message is received, in order to rule out causes of malfunctions that may occur in the respective system but are irrelevant to the specific fault message. This task (ruling out irrelevant causes of malfunctions) therefore no longer needs to be performed by on-site maintenance personnel based on their own experience.

[0010] Furthermore, a probability of occurrence is determined for each possible cause of the malfunction, and the causes are then listed in a sequence according to these probabilities. This provides maintenance personnel with information on which of the various possible causes is ultimately the most likely. This allows them to examine the causes of the malfunction according to this sequence, enabling them to identify the actual cause as quickly as possible. This also automates a process that traditionally requires considerable experience when repairing the specific system: determining which of the remaining possible causes is the most probable.The probabilities of the causes of the fault can be calculated, in particular, using data stored in the database, as explained in more detail below. However, it is also possible, in principle, for the probabilities of the causes of the fault to be directly read from the database and thus retrieved from the database.

[0011] While these steps enable the efficient identification and categorization of potential causes of malfunctions, the system also retrieves and displays possible repair measures from the database for each identified cause, indicating which measures can be applied to resolve the malfunction. Therefore, maintenance personnel are not only provided with information on the potential causes of a given malfunction, but also on the appropriate repair measures to resolve each specific cause.

[0012] Furthermore, this process not only identifies possible repair measures, but also determines a repair success probability for each repair measure assigned to a specific cause of the malfunction. This probability measures the likelihood of successfully resolving the malfunction. By then displaying the repair measures assigned to a specific cause of the malfunction in order of success probabilities, maintenance personnel can be informed which of the various possible repair measures is most likely to resolve the respective cause of the malfunction. The repair success probabilities can also be calculated, for example, using data stored in the database and / or read directly from the database.

[0013] In a sense, this approach allows for the technological advancement of know-how traditionally developed through years of experience in the repair of refrigeration systems and / or building technology systems, enabling even less experienced maintenance personnel to resolve malfunctions quickly and reliably. Furthermore, because the database can contain fault causes and corresponding repair measures for virtually any refrigeration system and / or building technology system, the need for maintenance personnel to specialize in specific refrigeration systems and / or building technology systems can be overcome.Based on the information stored in the database, sufficiently precise instructions can be generated to rectify the fault reported by a respective refrigeration system and / or building technology system, so that the maintenance personnel on site no longer need special experience regarding possible causes of faults and / or repair measures for the specific system, but only need to rely on general training in the repair of components of the respective system and thus in implementing the repair measures.

[0014] As explained in more detail below, the probabilities of fault causes and / or repair success can be determined, particularly on a frequency-based basis, by entering feedback into the database after each fault has been rectified. This feedback specifies the actual cause of the fault and the repair measure that led to the successful repair of the refrigeration system and / or building technology system. In particular, this approach can make it possible to compile the experience gained by different individuals repairing various refrigeration systems and / or building technology systems in the database, so that this experience can be accessed for subsequent repairs by retrieving data from the database.The multiple refrigeration systems and / or building technology systems - possibly from several different system operators - can therefore be combined in an analysis network in order to collect and use as much data as possible with regard to troubleshooting malfunctions in these systems.

[0015] Nevertheless, as will be explained in more detail below, measures can be taken to protect specific know-how regarding the troubleshooting of malfunctions in refrigeration systems or building technology systems by protecting certain causes of malfunctions and / or repair measures, which have been specifically identified by a system operator, from access by competitors when reading the database.

[0016] In the context of this disclosure, a plant operator potentially possessing specialized know-how could be, in particular, a user of a refrigeration system or building technology system, such as a supermarket operator. Such a plant operator may notice certain recurring problems and develop specific solutions to resolve these problems, which they wish to protect from unauthorized access.

[0017] However, for the purposes of this disclosure, an operator of a refrigeration system and / or building technology system may also be understood as an employee of a service and / or maintenance company, or as such a company itself, if service and / or maintenance personnel maintain and adjust the respective systems as part of a service. In particular, such service and / or maintenance companies may possess specialized knowledge or know-how regarding troubleshooting malfunctions in specific systems requiring maintenance and may also be in competition with other companies, meaning that the acquired specialized knowledge or know-how may need to be kept confidential.

[0018] Furthermore, it is also conceivable, for example, that a manufacturer of refrigeration systems and / or building technology systems may itself carry out maintenance or adjustments on delivered systems as necessary, so that a system operator who may have special knowledge regarding possible (system-specific) causes of malfunctions or (system-specific) repair measures may also be a system manufacturer within the scope of the present disclosure.

[0019] Therefore, it may be specifically intended that the procedural steps for reading the database, determining the probabilities of the causes of the fault and the repair measures, and outputting the causes of the fault are carried out on an analysis system remote from the refrigeration system or building technology system reporting the fault, for example, on an external server and / or cloud-based. The fault message can thus be received by such a server from the respective refrigeration system and / or building technology system via an internet connection, whereupon the associated causes of the fault and repair measures can be read from the database by the server.The server can then transmit the identified fault causes and the associated repair measures to the system sending the fault message or to a mobile receiving device used by maintenance personnel, such as a smartphone. This allows the fault causes and associated repair measures to be displayed on the system itself, for example on a monitor of a connected computer, or on the mobile receiving device. After the fault has been resolved, feedback regarding the actual fault cause and successful repair measure can be transmitted to the server and the database via the aforementioned internet connection, for example, using a smartphone or computer, in order to update the stored data.

[0020] To enable the transmission of fault causes and repair measures to a mobile receiving device, it can be implemented, for example, that the mobile receiving device transmits an output request to the server, thereby requesting the fault causes and / or repair measures associated with a particular fault message. For this purpose, information such as the fault message, a system identifier, or a location can be sent from the mobile receiving device to the server or the analysis system, for example, via an application (app) on a smartphone, to indicate to which receiving device the fault causes and repair measures should be transmitted. Furthermore, a specific fault message can be selected from a list of existing fault messages to request a display of the associated fault causes and repair measures.

[0021] In general, it can also be provided that the fault causes and the associated repair measures are displayed in a single step, for example on a computer monitor or the screen of a laptop, tablet, or smartphone, in order to give maintenance personnel an immediate overview of possible fault causes and suitable repair measures. Alternatively, it can also be provided, for example, that only the fault causes are initially displayed in the sequence of fault causes, so that maintenance personnel can, for example, select a respective fault cause to request the display of the associated repair measures in the sequence of repair measures.This allows maintenance personnel, for example, to be given an initial overview of possible causes of malfunctions, enabling them, for instance, to disregard causes of malfunctions that are probable based on the database data but which, according to the experience of the maintenance personnel, are excluded in the specific case.

[0022] Furthermore, it may also be possible to initially display only the most probable cause of the fault – possibly with the associated repair measures, or initially without any associated repair measures. Such a procedure can be used, for example, on relatively small screens, such as smartphone screens, to display only a manageable amount of data. For instance, following a command from maintenance personnel, such as a tap or swipe on a smartphone touchscreen, the next cause of the fault can then be displayed according to the fault sequence, once a specific cause has been checked and determined not to be present.

[0023] In general, the fault causes and / or repair measures issued in the procedure described here can be displayed, in particular, on a display device.

[0024] A refrigeration system can generally comprise one or more refrigeration units – possibly combined in a system – as well as one or more refrigeration units, particularly refrigerated display cases, which might be used, for example, in a supermarket to cool food products. However, it is also possible for a refrigeration system to consist of a single refrigerated display case, such as a refrigerator or freezer, which could be located in a supermarket, but also in a private household or other building. A building services system can, for example, include an air conditioning system, a heating system, and / or a ventilation system in a building, or be designed as one of these systems.

[0025] The probabilities of the causes of malfunctions and the probabilities of successful repairs can generally represent a measure that allows for a ranking of the causes of malfunctions and / or the repair measures relative to each other, according to the probability of a particular cause of malfunction occurring or of a particular repair measure being suitable for resolving the malfunction. However, it is not necessarily required to normalize the sum of the probabilities of the causes of malfunctions and / or the probabilities of successful repairs to one, as will be explained below.

[0026] Further embodiments are explained in the dependent claims, the description and with reference to the drawings.

[0027] In some embodiments, the probabilities of the causes of malfunctions and / or the probabilities of successful repairs can be output and / or displayed. In such embodiments, it can therefore be understood, for example, what differences exist in the probabilities of the respective causes of malfunctions and / or repair measures, so that maintenance personnel can adjust the sequence in which they address possible causes of malfunctions and / or apply repair measures based on their own experience, especially when there are only slight differences in the respective probabilities.

[0028] In some embodiments, the fault message can be encoded in an alarm message, which is transmitted by the refrigeration system or the building services system and received using the method described here. Furthermore, the fault message can then be decoded from the received alarm message.

[0029] In particular, the procedure described here can be used to facilitate and accelerate the repair of various refrigeration and / or building technology systems by pooling experience gained from troubleshooting malfunctions in such systems. To achieve this, as many refrigeration and / or building technology systems as possible, potentially from different operators, can be connected to the aforementioned analysis system to utilize data collected during the repair of numerous systems.

[0030] However, it is often intended and desired by operators of refrigeration systems and / or building technology systems to be able to define an alarm message to be issued in the event of a malfunction, in order to, for example, issue a clear and intuitive text message as an alarm message instead of standardized error codes. Therefore, the respective outputs of a refrigeration system or building technology system, through which alarm messages are issued, can be freely configured.

[0031] To maintain this freedom for operators of refrigeration systems and / or building technology systems and to avoid being fundamentally dependent on standardized fault messages, it may be possible to decode such arbitrarily worded alarm messages into a corresponding standardized fault message. For example, an alarm message "high temperature detected" can be decoded or projected onto the fault message "temperature exceedance in the cold storage room" in order to then retrieve the fault causes and repair measures associated with the decoded and ultimately standardized fault message from the database.

[0032] The alarm message can therefore be, in particular, a text message that is formulated in any way possible and describes the underlying fault.

[0033] In some versions, the decoding of the fault message can be done by a text AI (Artificial Intelligence).

[0034] In particular, such a text-based AI can decode a fault message—the core of the alarm message—from alarm messages that are formulated in any way imaginable, especially those originating from operators of refrigeration systems and / or building technology systems. This text-based AI can therefore determine the meaning of a received alarm message and project it onto a standardized fault message, from which information can then be retrieved from the database.

[0035] For example, a text-based AI can be trained to decode a fault message from a received alarm message by executing a machine learning algorithm and / or by using one or more neural networks. Such an algorithm and / or neural network can, for instance, be trained in previous steps using received alarm messages for which a standardized fault message to be transmitted is known.

[0036] Alternatively or in addition to using a text AI, some implementations may also store mappings between alarm messages and fault messages in the database.

[0037] In some embodiments, the (especially decoded) fault message can include information about the location of the fault in the refrigeration system and / or the building technology system.

[0038] For example, a fault message relating to a refrigeration system with several different refrigerated display cases can first include the affected display case, perhaps in the form of a device identifier, and then a specific component of the display case, in order to immediately inform maintenance personnel which unit and which component are experiencing a fault. Furthermore, the fault message can also include local information regarding the location of the affected refrigerated display case or, more generally, the affected system component, in order to guide external maintenance personnel to the affected system component as directly as possible.Such information can also be decoded from the aforementioned alarm message, in particular by including information about a device emitting the fault, whereby, for example, the database may also contain information about the location of the respective device, which can be included in the fault message.

[0039] In some designs, the alarm message can therefore be decoded by referring to the database.

[0040] Furthermore, in some embodiments, the fault message can be issued and / or displayed, particularly if the fault message includes information about the location of the fault.

[0041] In some embodiments, the probability of the cause of the fault can be determined as a conditional probability for a given fault message.

[0042] Such a determination of the probability of a fault cause takes into account, in particular, that the same fault cause can be assigned to different fault messages. For example, the fault cause of a defective expansion valve in a refrigeration system can be assigned to both the fault message "elevated temperature in the cold storage room" and the fault message "excessive pressure in the evaporator," although the probability that one of the two fault messages is actually due to the fault cause of a defective expansion valve can differ for each fault message. The probability of the fault cause being assigned to the fault cause "defective expansion valve" can therefore vary depending on the incoming fault message.

[0043] The probability of the cause of the malfunction and / or the probability of successful repair can be calculated for some embodiments.

[0044] In particular, it can therefore be provided that the probability of the fault cause and / or the probability of repair is recalculated for each incoming fault report by accessing information stored in the database. Alternatively, it can also be provided, for example, that fault cause probabilities or repair success probabilities are stored in the database, assigned to the respective fault causes and / or repair measures, so that the fault cause probabilities and repair success probabilities can be read from the database in such embodiments. However, even in this case, the repair success probabilities and fault cause probabilities to be stored in the database can be calculated and then stored and updated if necessary, although in this case the calculation step no longer has to take place after the receipt of a fault report.

[0045] In some embodiments, the probability of a fault cause can be determined as a frequency-based probability of fault cause based on the frequency of occurrence of the respective fault cause. To determine the frequency-based probability of fault cause, a total number of events associated with the respective fault message, as well as a number of events from the database where the respective fault cause is associated with the respective fault message, can be determined. The frequency-based probability of fault cause for the respective fault can then be determined as the ratio between the number of fault causes and the total number of fault messages.

[0046] Therefore, the database can contain counters for each event, with one of these counters counting the occurrence of a specific fault message as an event associated with that fault message, thus increasing the total number of fault messages for that particular fault. Furthermore, separate counters can be provided for fault causes, increasing the corresponding counter and updating the fault cause count as a result of a identified fault cause. Specifically, the counter for a fault message can be incremented immediately upon receipt of the fault message, while the counter for the fault cause can be incremented following feedback from maintenance personnel after the fault has been resolved, which transmits information to the database about the actual fault cause.By combining information on resolved malfunctions of multiple refrigeration systems and / or building technology systems, a comprehensive statistic can be generated in the database regarding the actual causes of malfunctions in each fault report. This allows for the sorting of likely fault causes by determining the frequency-based probabilities of a future fault report.

[0047] In particular, the database can contain counters for assigned fault causes for each fault report, so that, as a result of a identified fault cause, only the counter of the fault cause that is also assigned to the received fault report can be incremented. Therefore, by calculating the ratio between the number of fault causes and the total number of fault reports, the directly related probabilities of a fault cause being present for a given fault report can be determined.

[0048] In some embodiments, the causes of the fault may include at least one plant-specific cause of the fault, whereby the plant-specific cause of the fault can only be output when the fault message is received from a specific refrigeration system and / or building technology system.

[0049] Alternatively or additionally, it may also be provided that the plant-specific cause of the fault is only issued upon receipt of a request from a specific plant operator for the causes of the fault and repair measures associated with the fault message.

[0050] In principle, troubleshooting malfunctions in refrigeration systems and / or building technology systems can be the subject of research and development by system operators (especially system users, service and / or maintenance companies, or system manufacturers). In such cases, it may be desirable to protect specific insights gained from competitors, while simultaneously benefiting from the simplified maintenance and repair processes offered by accessing the database and integrating these specific insights for their own use. This tension can be addressed by ensuring that fault causes, identified as system-specific and stored in the database, are only displayed when a fault message is received from the corresponding system.This allows these system-specific causes of malfunctions to be integrated and output according to the sequence of causes, without, however, providing competitors of the respective system operator with information about the system-specific cause of the malfunction. This thus enables – even when refrigeration systems and / or building technology systems from different users are connected to a single analysis system – the reliable protection of specialized know-how or knowledge from disclosure.

[0051] Furthermore, such knowledge protection can be achieved by ensuring that the plant-specific fault cause is only released when a request to read the database is received from a specific and authorized plant operator, for example, a plant operator who has stored the respective fault cause in the database. This can be accomplished, for instance, by requiring an identification or authentication query before the fault causes are released.

[0052] For example, to retrieve the plant-specific cause of a fault, a password may need to be entered into a smartphone application when requesting fault causes. The database or a corresponding server can then check, based on the entered password, whether the user is authorized to query the plant-specific fault cause. Only after successful identification of the authorized or specific plant operator can the plant-specific fault cause be transmitted. Furthermore, it may also be possible, for example, to identify the specific plant operator using a device identification number from which a request for fault causes and repair measures associated with a fault message is sent.This may also include a login on the device or an application installed on it, to ensure that only authorized plant operators can read out the plant-specific causes of malfunctions.

[0053] To implement such a procedure, the plant-specific fault causes can be stored in the database, and upon receipt of a fault message, a probability of the fault being caused by the plant-specific fault cause can be determined – in particular, always – provided that this plant-specific fault cause is assigned to the received fault message. However, the output of the plant-specific fault cause can be suppressed if the fault message was received from a plant other than the one assigned to that plant-specific fault cause.For example, the database can contain a code for plant-specific fault causes, and received fault messages can include a code that identifies the respective origin of the fault message. Only if there is a match between the stored and received codes can the plant-specific fault cause be displayed. Alternatively, it can also be provided that plant-specific fault causes are excluded when determining the probability of the fault cause if the fault message was not received from that specific plant.

[0054] In some embodiments, a plant-specific fault cause probability that is higher than the determined frequency-based fault cause probability can be determined, especially if the fault message was received from the specific refrigeration system and / or building technology system.

[0055] Furthermore, in some embodiments, to determine the plant-specific probability of fault causes, the frequency-based probability of fault causes can first be determined based on the number of fault causes assigned to the plant-specific fault cause and the total number of fault messages, whereby the frequency-based probability of fault causes can then be multiplied by a weighting factor greater than 1.

[0056] By adjusting the plant-specific fault cause probability in this way, in particular based on the frequency-based fault cause probability determined for the plant-specific fault cause, it is possible to take into account the fact that the plant-specific fault cause can only occur in the specific plant and thus - especially when fault messages are received from different plants - only accounts for a relatively small proportion of the events that are assigned to a respective fault message.If the probability of a fault being caused by a plant-specific fault were determined solely based on frequency, like other fault causes, using the total number of fault reports and the number of fault causes, plant-specific fault causes would always have low probabilities and therefore only appear at the end of the fault cause sequence sorted by probability. However, by increasing the probability of a fault cause relative to the plant-specific fault cause, it can be taken into account when a fault report is received from the specific plant that the plant-specific fault cause is quite likely in this case, especially since the respective plant operator apparently assigns high weight to this plant-specific fault cause and wants to protect it from being discovered by competitors.When determining the probability of the cause of the fault, in addition to relative frequencies, the fact that the fault message was received by the specific system can be included as a further parameter in order to adjust the probability of the cause of the fault to the system-specific cause of the fault.

[0057] In a sense, the plant-specific fault cause probability can thus be artificially increased to achieve a prioritized output of the plant-specific fault cause in the fault cause sequence. Furthermore, such an increase in the plant-specific fault cause probability may result in the sum of all fault cause probabilities for fault causes assigned to the respective fault message being greater than 1 after the adjustment, while the individual fault cause probabilities still allow for a relative sorting of the fault causes according to the probability of a fault cause actually occurring.

[0058] As an alternative to increasing the probability of a plant-specific cause of failure, some embodiments may also provide that the plant-specific cause of failure and / or several plant-specific causes of failure are always displayed first or in the first position in the sequence of causes of failure. In such embodiments, it may therefore also be possible that no probability of failure is determined for the plant-specific causes of failure, and thus the plant-specific causes of failure are not integrated into the sequence of causes of failure according to the determined probability of a plant-specific cause of failure.

[0059] In some embodiments, the probability of successful repair can be determined as a conditional probability for a given cause of the malfunction.

[0060] This again takes into account the fact that respective repair measures may lead to the rectification of the fault in the case of different causes of the fault, although the probability of success in rectifying a fault by resorting to a respective repair measure may differ for different causes of the fault.

[0061] In some embodiments, the fault message can also be considered as a given condition when determining the conditional probability. In such embodiments, the probability of successful repair can thus be determined depending on two conditions: the presence of a specific fault message and the presence of a particular fault cause. This allows for consideration of the fact that the probability of successfully resolving a fault by resorting to a specific repair measure may depend not only on the fault cause but also on the fault message that was originally received. Ultimately, in such embodiments, a combination of the fault message and the queried fault cause can be considered as a given condition when determining the probability of successful repair.

[0062] In some embodiments, the repair success probability can be determined as a frequency-based repair success probability. To determine this frequency-based repair success probability, a number of events associated with each fault cause, as well as a number of repair events, can be retrieved from the database, where the respective repair measure is assigned to the respective fault cause. The frequency-based repair success probability for each repair measure can then be determined as the ratio between the number of repairs and the number of fault causes.

[0063] Therefore, determining the probability of successful repairs can ultimately be achieved by compiling knowledge about completed repairs. This involves counting the number of repair measures successfully implemented to resolve malfunctions and then relating this count to a number of malfunction causes, which represents the number of events in which the respective malfunction cause was identified. Based on the data stored in the database, it is then possible to determine which repair measure is most likely to resolve a given malfunction cause.

[0064] In particular, the database for fault causes can therefore contain counters for each cause in order to record corresponding repair events. The data associated with each fault report can further comprise data arranged in three levels: the first level contains the total number of fault reports, the second level contains the number of fault causes for each associated cause, and the third level contains the number of repairs for each repair measure assigned to that cause. The described relationships can therefore directly determine the aforementioned conditional probabilities.

[0065] In some embodiments, the repair measures may include at least one plant-specific repair measure, wherein the plant-specific repair measure is issued exclusively upon receipt of the fault message from a specific refrigeration system and / or building technology system.

[0066] Alternatively or additionally, it may also be provided that the plant-specific repair measure is issued exclusively upon receipt of a request from a specific plant operator regarding the causes of the fault and the repair measures associated with the fault report.

[0067] As already explained in connection with plant-specific causes of malfunctions, the development or discovery of suitable repair measures to rectify a malfunction can also be the subject of research and development by plant operators (especially plant users, service and / or maintenance companies, or plant manufacturers), whereby specific knowledge should, if necessary, be protected from access by competitors. This can also be achieved, in particular, by releasing such plant-specific repair measures exclusively to the respective specific plant operator when a fault report is received from a specific refrigeration system and / or building technology system, or when a request for repair measures is received from the specific plant operator.This can again be achieved, for example, by including information about the sending system in a transmitted fault message (or alarm message) and / or by identifying the requesting system operator upon receipt of a request for fault causes and repair measures, for example by logging into an application on a smartphone or by entering a password.

[0068] Alternatively or additionally, in some embodiments, the output of a plant-specific cause of fault and / or repair measure may also require an authentication check, for example, a password entry.

[0069] For some embodiments, a plant-specific repair success probability can be determined that is higher than the frequency-based repair success probability for the plant-specific repair measure.

[0070] Furthermore, to determine the plant-specific repair success probability in some embodiments, the frequency-based repair success probability can first be determined based on the number of repairs assigned to the plant-specific repair measure and the number of fault causes, whereby the frequency-based repair success probability can then be multiplied by a weighting factor greater than 1.

[0071] As already explained in connection with plant-specific fault causes, this approach addresses the fact that plant-specific repair measures are not used for faults resolved in other plants and therefore cannot be reported back. Consequently, plant-specific repair measures have a comparatively low probability of success based on frequency. However, when a fault message is received from the specific plant, these very plant-specific repair measures can be promising. Therefore, prioritizing the display of plant-specific repair measures in the repair sequence can be useful. To achieve this, the plant-specific repair measure can be assigned the aforementioned increased probability of success.

[0072] Furthermore, some embodiments may prioritize plant-specific repair measures and display them before non-plant-specific repair measures in the repair sequence. In such embodiments, it may also be possible to determine no probability of success for plant-specific repair measures, but instead to assign them directly to a specific cause of the malfunction, prioritizing them accordingly.

[0073] Furthermore, some embodiments may provide for the ability of a plant operator to store plant-specific causes of malfunctions and / or repair measures in the database. In this respect, for example, a specific repair measure developed by a plant operator can be transmitted to and stored in the database, allowing the repair measure to be displayed when a fault message is received from the specific plant, while preventing its transmission to competitors. Plant-specific causes of malfunctions and / or repair measures can be stored with a corresponding identifier for this purpose.

[0074] In some embodiments, fault causes and / or repair measures can be added to the database, whereby an added fault cause can initially be assigned a fault cause probability of 1 and / or an added repair measure can initially be assigned a repair success probability of 1. The fault cause probability of the added fault cause and / or the repair success probability of the added repair measure can subsequently be determined upon receipt of a fault message, particularly based on the frequency of occurrence of the added fault cause or the added repair measure.

[0075] Adding fault causes and / or repair measures in this way allows the database to be continuously updated and to reflect new developments in refrigeration systems and / or building technology systems, or new insights gained from troubleshooting. To initially assign a fault cause probability or repair success probability of 1 to an added fault cause and / or repair measure, the database can be set to initially store a fault cause count of 1 and a total fault message count of 1 for the added fault cause. Similarly, for an added repair measure, an initial repair count of 1 and a fault cause count of 1 can be stored.After adding the cause of the fault and / or the repair measure, fault events and repair events can then be counted again - especially from the time of adding the cause of the fault and / or the repair measure - in order to determine the actual fault cause probabilities and repair success probabilities.

[0076] Therefore, in some embodiments, the total number of fault messages may differ for different fault causes associated with a single fault message, and / or the number of fault causes differ for different repair measures associated with a given fault cause, particularly depending on the time at which the respective fault cause and / or repair measure is added. This may also result in the fault cause probabilities and / or repair success probabilities not being normalized to one, but nevertheless allowing for a relative sorting of the fault causes and / or repair measures.

[0077] Furthermore, in some embodiments, it may be provided that added fault causes and / or added repair measures are only output at a later time and after the receipt of several fault messages, particularly those fault messages that can be associated with the added fault cause and / or repair measure. This can ensure, in particular, that the fault cause probability and / or repair success probability, initially set to a value of 1, first approximates a realistically probable fault cause probability and / or repair success probability before the fault cause and / or repair measure is output in the fault cause sequence or the repair measure sequence.In a sense, such a later activation can prevent a newly added fault cause or repair measure from being displayed in the first position of the fault cause sequence or the repair measure sequence due to the fault cause probability or repair success probability initially set to 1, even though the actual fault cause probability or repair success probability is not yet known.

[0078] In some embodiments, after a fault has been rectified, information about the actual cause of the fault and information about a successful repair measure can be received and stored in the database. Specifically, the information about the actual cause of the fault can be stored in the database as a fault event associated with the fault cause in the received fault message, and / or the information about the successful repair measure can be stored in the database as a repair event associated with the repair measure for the actual fault, in order to increment the aforementioned counters.

[0079] In some versions, real-time data from the refrigeration system or the building technology system can be received.

[0080] For example, the real-time data may include settings of the refrigeration system or building technology system, measured values ​​recorded by corresponding sensors of the refrigeration system or building technology system, or information about a configuration of the refrigeration system or building technology system, for example about devices included by the refrigeration system or building technology system, or respective system identifications.

[0081] In some embodiments, the received real-time data can be taken into account when determining the sequence of causes of malfunctions and / or the sequence of repair measures. In particular, the probabilities of the causes of malfunctions and / or the probabilities of successful repairs can be determined in some embodiments depending on the received real-time data.

[0082] In some embodiments, the probability of a fault cause and / or the probability of successful repair can be determined solely based on the received real-time data. For example, probable fault causes and / or promising repair measures can be inferred from a combination of received real-time data. A neural network can be used, for instance, to infer probable fault causes and / or repair measures from real-time data. Alternatively, the system can determine only the fault causes based on the real-time data and sort them according to their probabilities, while the probabilities of successful repair can still be determined, for example, based on frequency.

[0083] However, it is also possible that the real-time data is used solely to adjust a frequency-based probability of fault causes and / or probability of repair success.

[0084] The determined probabilities of the causes of the malfunction and / or the determined probabilities of successful repair can be adjusted in some embodiments depending on the received real-time data, in particular multiplied by a weighting factor.

[0085] In this context, the determined fault cause probabilities and / or repair success probabilities may, in particular, be the aforementioned frequency-based fault cause probabilities and / or frequency-based repair success probabilities and / or respective system-specific fault cause probabilities and / or system-specific repair success probabilities. Therefore, in such embodiments, the sequence of fault causes and / or the sequence of repair measures can, in principle, initially be determined based on experience with repairs following an incoming fault message and thus on a frequency basis. However, received real-time data can be taken into account to adjust the sequence of fault causes and / or the sequence of repair measures as necessary.

[0086] For example, real-time data can be used to conclude that a fault cause that is generally probable when a particular fault report is received is unlikely to actually be present. This finding can be taken into account by multiplying the frequency-based probability of the fault cause by a weighting factor to achieve a better ranking of the fault causes. For example, an elevated temperature in a cold storage room of a refrigeration system could, in principle, be caused by a defective expansion valve.However, if real-time data shows that the opening degree of the expansion valve can always be properly adjusted as a result of corresponding control commands, this may indicate that the expansion valve is functioning correctly and that the cause of the malfunction is not a malfunction of the expansion valve, so that the cause of the malfunction of a defective expansion valve can be considered less likely in this case.

[0087] To adjust the frequency-based determined fault cause probabilities and / or determined repair success probabilities, the fault cause probabilities and / or the repair success probabilities can, for example, be determined both frequency-based and on a real-time basis in order to output an average of the probabilities determined by the two methods as the adjusted fault cause probability and / or adjusted repair success probability.

[0088] In some designs, causes of malfunctions and / or repair measures can be ruled out based on the received real-time data.

[0089] For example, a possible cause of a particular fault message may be ruled out based on the received real-time data, meaning that no fault cause needs to be displayed in this case. For instance, a fault message indicating an elevated temperature in a refrigeration system's cold storage room could be caused by an excessively high temperature setpoint. The fault message might be generated, for example, if the elevated temperature is detected as a deviation from a predefined good state. This means that a fault cannot be solely attributed to a deviation from a setpoint; instead, an additional check of a predefined good state is performed. However, if the real-time data shows that the temperature setpoint is correct and, for example, set according to the good state, this cause of the fault can be ruled out.Likewise, the repair measure "reducing the temperature setpoint" can also be ruled out in this case.

[0090] Furthermore, it may be stipulated that a cause of the fault and / or a repair measure ruled out based on the real-time data will not be output.

[0091] Alternatively or additionally, some embodiments may also provide for the prioritized output of fault causes and / or repair measures based on the received real-time data.

[0092] Prioritizing fault causes and / or repair measures based on received real-time data can, in particular, enable a plant operator to demand specific repair measures based on certain real-time data points and / or a combination of such data points, thereby ensuring that these repair measures are implemented. Specifically, this allows a plant operator, for example, to ensure that a potentially critical component is always inspected when certain real-time data points are present, even if a failure of this component is less likely than other fault causes.

[0093] Prioritization can generally mean assigning an item to a higher rank in the sequence of causes of failure and / or in the sequence of repair measures.

[0094] In some embodiments, the real-time data may include pressure, pressure change, temperature, temperature change, valve opening degree, control setpoint, device identification, further fault messages from the refrigeration system or building technology system and / or a fault message from another refrigeration system or building technology system located at the same location as the refrigeration system or building technology system.

[0095] Therefore, real-time data can, in principle, include information about parameters of the respective refrigeration system or building technology system in order to deduce potential causes of malfunctions and / or suitable repair measures based on these parameters. Furthermore, some configurations can take into account whether the refrigeration system or building technology system and / or neighboring refrigeration systems or building technology systems are receiving further fault messages, in order to consider, for example, the presence of combinations of fault messages when determining the probabilities of the causes of malfunctions and / or the probabilities of successful repairs.Such an approach can, for example, take into account that certain causes of malfunctions may directly lead to several fault reports or a chain of malfunctions, so that the presence of a corresponding combination of fault reports in temporal correlation to each other can indicate the presence of the respective cause of the malfunction and suitable repair measures.

[0096] Accordingly, the probability of the fault being caused and / or the probability of the repair being successful associated with this fault cause can be adjusted, for example by a weighting factor, and / or a prioritized output of the respective fault cause or repair measure can generally be provided.

[0097] In some designs, multiple fault messages can be received and the fault messages can be prioritized based on the received real-time data.

[0098] Generally, when receiving multiple fault messages, the problem can arise that the underlying faults must be addressed sequentially, although not all faults are necessarily equally serious. For example, some faults in a refrigeration system may require repair but only affect the system's efficiency, whereas other faults can lead to damage to goods if not resolved promptly. However, if, for instance, the less critical fault is addressed first, significant product loss could occur.

[0099] To avoid this, real-time data can be used to check the progress of each fault, ensuring that maintenance personnel can address serious issues first. For example, upon receiving a fault message indicating an elevated temperature in a refrigeration unit's cold storage room, real-time data can be used to determine the deviation from the desired temperature, enabling the refrigeration unit with the greatest temperature deviation to be repaired first. Furthermore, multiple fault messages originating from the same location can be prioritized and addressed. This allows, for instance, the immediate resolution of fault messages from a supermarket or building generating numerous reports.

[0100] In general, fault reports can be prioritized according to the impact or potential impact of the fault underlying each report. These impacts may relate to the functionality of the refrigeration system or building services system, or—particularly with regard to refrigeration systems—to a risk to protected goods or building components posed by the refrigeration system or building services system.

[0101] As a result of prioritizing fault messages, an output can be generated in which the fault messages are arranged in a sequence according to the prioritization, in order to be processed accordingly.

[0102] In some embodiments, decaying faults can be detected using real-time data, and fault messages relating to decaying faults can be given lower priority. Furthermore, in some embodiments, it may be provided that, instead of fault causes and repair measures, information about the decay of the fault can be output for decaying fault messages.

[0103] For example, when a fault message is received indicating an elevated temperature in a refrigeration unit's cold storage room, real-time data can be used to detect that the temperature is already decreasing and approaching a predefined setpoint. In this case, it can be concluded that the temperature increase was merely a temporary and random occurrence, perhaps due to a refrigerated display case being opened, and that the refrigeration system is ultimately functioning correctly. In this scenario, the fault message can be given a lower priority, and since no repair of the refrigeration system may be necessary at all, instead of providing information on the cause of the fault and / or repair measures, a message can be issued indicating that the fault is already resolving. This can prevent unnecessary maintenance and repair work.

[0104] Furthermore, in some configurations, receding faults can be monitored using real-time data, for example, for a specified period and / or until the fault has completely receded. If a fault initially detected as receding intensifies, the corresponding fault message can be prioritized again and / or associated fault causes and / or repair measures can be displayed.

[0105] In some embodiments, multiple fault messages can be received and the fault messages can be prioritized based on expected fault chains, which represent a probability of a subsequent fault occurring.

[0106] For example, certain malfunctions in a refrigeration system or building services system can lead to further malfunctions, such as in other components, if these malfunctions are not rectified. If, for instance, an expansion valve upstream of a refrigeration system's evaporator is permanently open too wide, this can lead to flooding of the evaporator, potentially allowing liquid to enter a compressor and damage it. Such a malfunction, which can trigger further malfunctions and compressor damage, can therefore be considered more serious than malfunctions affecting only a single component without endangering the entire refrigeration or building services system. To ensure that serious malfunctions are addressed first, fault reports can be prioritized based on such anticipated chains of events.

[0107] In some implementations, received real-time data can be considered when determining expected fault chains. For example, the presence of a particular fault message in conjunction with a specific combination of received real-time data can indicate an impending subsequent fault and thus a fault chain. A neural network, for instance, can also be used to assess the probability of a fault chain occurring.

[0108] In some embodiments, if a subsequent fault occurs as a result of a fault message, information about the occurrence of the subsequent fault can be stored in the database. In this way, knowledge about the occurrence of subsequent faults following a received fault message can be generated, enabling the probability of subsequent faults to be determined in the future and taken into account when prioritizing fault messages.

[0109] In some embodiments, a prediction of the occurrence of a chain of faults can be determined upon receipt of a fault message.

[0110] In particular, information stored in the database regarding subsequent faults recorded when a fault message occurred, and / or received real-time data, can be taken into account. Such historical information on fault chains and / or available historical real-time data can also provide training data for a predictive algorithm to forecast the impending occurrence of a fault chain in future fault messages, which in turn can be used to prioritize the fault messages.

[0111] The invention further relates to an analysis system for analyzing malfunctions in a refrigeration system and / or a building services system, which includes an interface at which fault messages from the refrigeration system or the building services system can be received. The analysis system also includes a database in which fault causes and repair measures are stored, a control unit connected to the interface and the database, and an output device. The control unit is configured to determine one or more fault causes associated with the received fault message from the database and, for each of the determined fault causes, to determine a fault probability associated with the respective fault cause as well as one or more repair measures associated with the respective fault cause from the database.Furthermore, the control unit is designed to determine a repair success probability for each repair measure assigned to the respective cause of the fault, and to sort the causes of the fault in a fault cause sequence according to the determined fault cause probabilities, and to sort the repair measures assigned to each cause of the fault in a repair measure sequence according to the determined repair success probabilities.Furthermore, the control unit is designed to output the identified causes of malfunctions according to the sequence of causes of malfunctions, as well as the assigned repair measures according to the sequence of repair measures, to the output device, and the output device is designed to display the causes of malfunctions according to the sequence of causes of malfunctions and the repair measures assigned to each cause of malfunction according to the sequence of repair measures.

[0112] As explained above, such an analysis system can thus facilitate the analysis of malfunctions present in a refrigeration system and / or building technology system, in order to be able to immediately point out to the maintenance personnel to probable causes of malfunctions and to take repair measures.

[0113] In general, the control unit can be connected to the output unit via a wired or wireless connection, in particular a WLAN / WiFi connection, a cellular connection, or a Bluetooth connection. The output unit can, in particular, include a monitor or screen for displaying the respective causes of malfunctions and repair measures. Specifically, the output unit can be a smartphone or other mobile receiving device to transmit the causes of malfunctions and repair measures to maintenance personnel located on-site at the refrigeration system or building technology system. The control unit, on the other hand, can, for example, be located on a central server and may include, in particular, a microprocessor and / or a CPU.

[0114] In some embodiments, the fault message can be encoded within an alarm message. The alarm message can be received at the interface. Furthermore, in such embodiments, the control unit can be configured to decode the fault message from the received alarm message, particularly using text-based AI (artificial intelligence). As already explained, this can allow plant operators to encode alarm messages in any way they wish, especially with any text, and the control unit can be configured to project received alarm messages onto standardized fault messages.

[0115] In some embodiments, the analysis system may also include an interface for receiving real-time data from the refrigeration system or the building services system. This could be, for example, the same interface used for receiving fault messages or a separate interface. As already explained, this can, in particular, enable the control unit to consider real-time data in order to determine and / or adjust the probabilities of fault causes and / or repair success, and / or to prioritize fault messages.

[0116] Furthermore, in some embodiments, the analysis system can include a feedback device for reporting the actual cause of a malfunction and the successful repair measure. This allows, in particular, for updating the database to determine and output updated probabilities of malfunction causes and / or repair success. The feedback device can, for example, also be integrated into a maintenance personnel's smartphone to provide them with feedback regarding the actual cause of the malfunction and the successful repair measures.

[0117] In general, the analysis system, and in particular its control unit, can also be configured to perform one or more of the steps mentioned above in connection with the method for analyzing incoming fault messages. Furthermore, features mentioned above in connection with the method disclosed herein can also be implemented individually or in combination in the described analysis system.

[0118] In some embodiments, the analysis system may also include at least one refrigeration system and / or at least one building services system. The refrigeration system and / or building services system may further – generally and particularly in such embodiments – include sensors for acquiring real-time data, for example, pressure sensors or temperature sensors.

[0119] The invention is explained below by way of example with reference to the drawing.

[0120] They show: Fig. 1 A schematic representation of an analysis system for analyzing fault messages from a refrigeration system and / or a building technology system, wherein the fault messages are received here by way of example from a refrigeration system, Fig. 2 a schematic representation of components of the refrigeration system, Fig. 3 a schematic representation of a procedure to be carried out by a control unit of the analysis system for analyzing disturbances, Fig. 4. An illustration of the structure of a database associated with the control unit and Fig. 5 A schematic representation of a procedure to be carried out by the control unit to prioritize several incoming fault messages.

[0121] Fig. Figure 1 schematically shows an analysis system 11, which is designed to receive and analyze fault messages M from a refrigeration system 33 or – alternatively – from a building services system not shown, such as an air conditioning, heating, or ventilation system. The refrigeration system 33 is shown here as an example of a refrigerated display case or refrigerator, which can be used, for example, in a supermarket to cool food products. In particular, however, such a refrigeration system 33 can comprise a network of several refrigerated display cases and, for example, several refrigerators and freezers, which can also be operated at different temperature levels in order to store, for example, frozen goods or goods requiring higher temperatures.

[0122] The basic operating principle of such a refrigeration system 33 is schematically illustrated by means of Fig. Figure 2 illustrates the refrigeration system 33, which includes an ejector 15, two expansion valves 45, and a shut-off or control valve 46. A control device 79 is also provided, which is designed to actuate, via control lines 81, respective actuators for moving the closing elements of the valves 45 and 46 and the ejector 15, thereby stopping the operation of the refrigeration system 33.

[0123] The illustrated refrigeration system 33 comprises a container 43 for collecting refrigerant, an evaporator 39, a compressor 41, and a condenser 37. The refrigerant is guided through lines 47, with arrows indicating the direction of refrigerant flow. Refrigerant supplied to the evaporator 39 from the container 43 via an expansion valve 45 can evaporate in the evaporator 39, thereby extracting heat from the surroundings. The evaporator 39 produces a mixture of gaseous and liquid refrigerant, which can be drawn off by the ejector 15 via its suction port 53 and pressurized to a higher level.A gaseous portion of the refrigerant present in the container 43 can also be drawn in by the compressor 41 via line 47 and fed to the condenser 37, where the refrigerant is liquefied and can be discharged via a throttle valve 45 to the container or via the shut-off or control valve 46 to the ejector 15 as a motive fluid. During condensation, heat is released to the environment, so that, depending on the arrangement of the evaporator 39 and the condenser 37, the refrigeration system 33 can optionally also be used as a heating system, for example, for heating a building. In order to monitor the system operation and acquire real-time data E, the refrigeration system 33 also has a temperature sensor 73 and a pressure sensor 75 on the evaporator 39, and corresponding sensors, not shown, may also be provided on other components.In addition, the refrigeration system 33 has a radio device 71 to transmit fault messages M and / or real-time data E to the analysis system 11.

[0124] In principle, malfunctions can occur in such refrigeration systems. However, due to the multitude of possible configurations of such refrigeration systems, or indeed of building technology systems, extensive experience is often required to resolve a malfunction as quickly and accurately as possible. However, particularly in the area of ​​refrigeration systems, a rapid resolution of malfunctions can be crucial to prevent, for example, damage to perishable goods due to a persistently elevated temperature in a cold storage room being cooled by the refrigeration system.

[0125] To address this problem and enable the fastest and most convenient possible resolution of malfunctions, the aforementioned analysis system 11 is designed to perform a particularly thorough analysis based on Fig. The illustrated procedure is to be carried out, wherein in step 55 the fault message M is first received from the refrigeration system 33 at an interface 13 of the analysis system. In particular, it is provided that the refrigeration system 33 sends out an alarm message A, which can be freely formulated, for example by an operator of the refrigeration system 33, and in which the fault message M, for example "elevated temperature in the cold storage room", is encoded. The alarm message A is therefore received at the interface 13 of the analysis system 11 and initially transmitted to a decoding device 27, which is part of a control unit 19 of the analysis system 11. In step 57, the decoding device uses artificial intelligence to decode the standardized fault message M "elevated temperature in the cold storage room" from the alarm message A, so that the control unit 19 ultimately has the fault message M.Such a procedure can, in particular, enable the operator of the refrigeration system 33 to formulate alarm messages A arbitrarily and intuitively, without being bound to standardized error codes.

[0126] Based on the decoded fault message M, the control unit 19 can, in a subsequent step 59, read a database 17 connected to the control unit 19 in order to record associated fault causes U and suitable repair measures R. The structure of the database 17 is particularly evident from the following: Fig. 4. Illustrated by example. The expert understands that Fig. 4. A possible structure of the database 17 and the data stored therein is illustrated only as an example and in part, but by no means conclusively, and various other fault messages M, fault causes U and / or repair measures R or other data may be stored therein.

[0127] Database 17 contains, in particular, potentially underlying fault causes U for each fault message M, and each of the possible fault causes U is assigned respective repair measures R that may be suitable for remedying the respective fault cause U. For example, according to Fig. 1 received fault message M1 “increased temperature in the cold storage room” come according to Fig. 4. Possible causes of malfunctions U1 and U2 include, for example, an incorrect opening degree of an expansion valve or an incorrect setpoint, especially for the temperature.

[0128] Furthermore, database 17 contains a total number of fault messages G1 of events for which the respective fault message M1 was received, for example 5142. In addition, for each of the fault causes U1 and U2, a respective fault cause count G2 is stored, which represents the number of events for which, given a fault message M1, the respective fault cause U1 or U2 would actually be determined.

[0129] Each of the fault causes U1 and U2 is then assigned corresponding possible repair measures R1, R2, or R3. For example, fault cause U1, "Incorrect opening degree of expansion valve," is assigned repair measures R1, "Open expansion valve," and R2, "Replace expansion valve," whereas fault cause U2, "Incorrect setpoint," is assigned only repair measure R3, "Reduce setpoint." For each of the possible repair measures R1 to R3, a corresponding repair number G3 is also stored, reflecting events in which the respective repair measure R1 to R3 actually resolved the fault.

[0130] Reading database 17 in step 59 thus enables the control unit 19 to determine the fault events U1 ("incorrect opening degree of expansion valve") and U2 ("incorrect setpoint") associated with the received or decoded fault message M. Furthermore, the two possible repair measures R1 ("open expansion valve") and R2 ("replace expansion valve") can be assigned to the fault cause U1.

[0131] As explained in more detail below, the fault causes U and the repair measures R can also include respective plant-specific fault causes K1 and plant-specific repair measures K2, so that the control unit 19 in the procedure according to Fig. 3 in one step 35 can check whether each of the read-out fault causes U1 and U2 or each of the read-out repair measures R1 to R3 is coded as plant-specific.

[0132] In the example according to Fig. 1 and the received fault message M1 “increased temperature in the cold room”, however, none of the fault causes U1 or U2 and none of the repair measures R1 to R3 are marked as plant-specific, so that without considering such plant-specific fault causes U or repair measures R, it is possible to proceed to step 61, in which the fault causes U1 and U2 and the two repair measures R1 and R2, which are assigned to the fault cause U1, are sorted.

[0133] In step 63, a probability W1 for each of the two fault causes U1 and U2 is determined by dividing the number of fault causes G2 assigned to each fault cause U1 or U2 by the total number of fault messages G1 assigned to fault message M1. This allows the fault cause probabilities W1 for faults U1 and U2 to be determined as the respective conditional probability with which each fault cause U1 or U2 is present for the given fault message M1.

[0134] Furthermore, in step 65, a repair success probability W2 is determined for each of the two repair measures R1 and R2, which are assigned to fault cause U1, by dividing the number of repairs G3 assigned to the respective repair measures R1 and R2 by the number of fault causes G2. Thus, both the fault cause probabilities W1 and the repair success probabilities W2 are determined based on frequency and also as conditional probabilities. To determine the fault cause probability W1, the presence of fault message M is assumed, and to determine the repair success probabilities W2, a specific fault cause U1 or U2 is assumed to be present when fault message M1 is present. Since only repair measure R3 is assigned to fault cause U2, a repair success probability of 1 can be assigned to it.

[0135] After the fault cause probabilities W1 and the repair success probabilities W2 have been determined, the fault causes U1 and U2 are arranged in a fault sequence S1 according to the determined fault cause probabilities W1, and the two repair measures R1 and R2 assigned to fault cause U1 are arranged in a repair sequence S2 according to the determined repair success probabilities W2. Subsequently, the fault causes U1 and U2 recorded for fault message M1 according to fault sequence S1, and the repair measures R1 and R2 for fault cause U1 according to repair sequence S2, are output as output 77 of analysis system 11 in step 67.

[0136] To enable this output, the control unit 19 includes, in particular, a radio device 21 with which the analysis system 11 communicates with a mobile receiving device 23, which is exemplified here as a smartphone and which functions as an output device 24. Such transmission can therefore enable a plant operator or their on-site maintenance personnel to immediately obtain information, as a result of the transmitted alarm message A with the encoded fault message M, about the most likely cause of the fault U and the most likely repair measures R to be applied to remedy the respective cause of the fault U. The analysis system 11 can thus, in a sense, provide a technologically advanced experience in troubleshooting such refrigeration systems 33, in order to facilitate the proper and rapid resolution of any malfunctions that occur.The fault causes U1 and U2 can be displayed, in particular, on the receiving device 23. Furthermore, it can be generally provided that the receiving device 23 transmits a request to the database 17 for the fault causes U and repair measures R associated with the specific fault message M, in order to obtain or retrieve the aforementioned information. This can also be done, for example, by selecting a specific fault message M from a list of existing fault messages M in an application on the receiving device 23.

[0137] Furthermore, the smartphone also functions as a feedback device 25, through which, after a fault has been rectified, information I about the actually determined fault cause U and a repair measure R used to rectify the fault can be transmitted to the analysis system 11 in order to be stored in the database 17. In particular, the corresponding fault cause count G2 and the repair count G3 can be increased as a result of such feedback in order to be able to determine the respective fault cause probabilities W1 and repair success probabilities W2 in an updated manner.

[0138] The analysis system 11 thus makes it possible to provide a technologically advanced expertise regarding the rectification of malfunctions in such refrigeration systems 33 or building technology systems by building a large statistic on successful repairs and thus, in a sense, by pooling experiences gained on various refrigeration systems 33 or building technology systems and especially on systems of various plant operators.

[0139] However, some plant users may prefer to keep secret any fault causes U or repair measures R discovered through their own research and not share them with competitors, but nevertheless include them in the analysis system 11 in the event of a fault in their own plant.

[0140] To enable such protection of specific know-how or knowledge, the fault causes U and / or the repair measures R can, as already mentioned, include plant-specific fault causes K1 or plant-specific repair measures K2, which are only issued when a fault message M is received from a specific plant or a request for the fault causes U and repair measures R associated with the fault message M is received from a specific plant operator. For example, in Fig. Figure 4 shows that several fault causes U can be stored for the fault message M2 "increased compressor output requested", whereby the fault cause "too few compressors switched on" constitutes a plant-specific fault cause K1, which is coded in database 17. The corresponding repair measure "activate additional compressor" also represents a plant-specific repair measure K2. In particular, the plant-specific fault cause K1 and the plant-specific repair measure K2 can be entered into database 17 by an operator of a specific refrigeration system 33, in which a variable number of compressors can be switched on, whereby the fault cause K1 and the corresponding repair measure K2 are not to be shared with other participants in the analysis system 11.

[0141] To ensure the desired protection of knowledge, only the general fault causes U3 "incorrect temperature setpoint" or U4 "compressor defective" with their associated repair measures R4 "increase temperature setpoint" and R4 "replace compressor" can be output following a received fault message M2 "increased compressor output," whereas the system-specific fault cause K1 "too few compressors activated" is only output if the fault message M2 is received by the specific system (refrigeration system or building services system) or requested by the specific system operator. Accordingly, the system-specific repair measure K2 "activate additional compressor" is also only output upon receipt of the fault message M2 by the specific system or upon receipt of the request from the specific system operator.The expert understands that, for example, the fault message M1 could be assigned a plant-specific fault cause or the fault cause U1 a plant-specific repair measure, and that an output of this plant-specific data could only take place if the fault message M1 is received by the specific plant.

[0142] Furthermore, to account for the fact that plant-specific fault cause K1 and plant-specific repair measure K2 occur or are reported less frequently than generally accessible or known fault causes U and repair measures R, a weighting factor B can also be stored in database 17. This factor is used to multiply the fault cause probability W1 or repair success probability W2 determined for each plant-specific fault cause K1 or repair measure K2, thus increasing the respective fault cause probability W1 or repair success probability W2. This ensures that plant-specific fault cause K1 or plant-specific repair measure K2 is ranked S1 or S2 in the fault cause sequence.The repair measure sequence S2 is prioritized for output because, despite the low statistical frequency, the system-specific fault cause K1 is ultimately likely to be present when the fault message M2 is received from the specific system. Alternatively, it can be provided, for example, that system-specific fault causes K1 and / or system-specific repair measures K2 are always output first (or, if there are multiple system-specific entries in database 17, in the first positions), and that no associated fault cause probabilities W1 or repair success probabilities W2 are determined for system-specific fault causes K1 or system-specific repair measures K2. As an alternative to storing a weighting factor in database 17, a calculation of this factor can also be provided.

[0143] In general, therefore, fault causes U and / or repair measures R, in particular as plant-specific fault causes and / or repair measures, can be stored in the database, also by operators of refrigeration systems 33 and / or building technology systems.

[0144] Fig. Figure 1 further illustrates that, in addition to the alarm message A and the fault message M encoded therein, the analysis system 11 can also receive real-time data E from the refrigeration system 33, which may include, for example, temperature, pressure, configuration of the refrigeration system 33, and / or identification of the refrigeration system 33 or of a specific refrigerated display case from which the alarm message A originates. The control unit 19 can be configured to take the real-time data E into account when determining the sequence of fault causes S1 and / or the sequence of repair measures S2.For example, the control device 19 can be trained to adjust frequency-based fault cause probabilities W1 or repair success probabilities W2 determined above based on the received real-time data E and, for example, to multiply them by a weighting factor in order to take the real-time data E into account when determining the fault cause sequence S1 and / or the repair action sequence S2.Alternatively, it can also be provided that the control device 19 is designed to determine, on its own and for example by means of a neural network, the respective possible causes of fault U based on the received real-time data E and the received fault message M, and, if necessary, to determine the associated probabilities of fault causes W1, whereby the repair measures R assigned to the respective causes of fault U can, in particular, be sorted and output on a frequency basis.

[0145] Fig. Figure 5 also shows a procedure executable by the control unit 19 of the analysis system 11 for prioritizing several incoming fault messages M1 and M2. In particular, the fault messages M1 and M2 can be received in a respective step 49 or 50, whereby in a step 29, additionally transmitted real-time data E and any information on fault chains C, which may be assigned to the respective fault message M1 and M2, are checked. How in turn Fig. As illustrated in Figure 4, such a fault chain C can be retrieved in database 17, for example by recording that, as a result of the received fault message M2 “excessive compressor power requested”, a subsequent fault N “increased temperature in the cold room” often occurs, thus creating a fault chain C.

[0146] The received real-time data E can be used, for example, to detect faults that are already subsiding. If, for instance, the fault message M1 "elevated temperature in the cold storage room" is received and the real-time data E indicates that the temperature is already decreasing, a subsiding fault can be detected. This allows the corresponding fault message M1 to be given a lower priority, and repairs are unlikely to be necessary. Furthermore, the real-time data E can, for example, make it possible to quantify the impact of a fault and, for instance, the magnitude of any deviation from target operation caused by the fault, such as a deviation from a target temperature, and consequently prioritize fault messages M accordingly.

[0147] Based on the examination of the real-time data E and possible fault chains C, the control unit 19 can sort the received fault messages M1 and M2 in step 51 in order to output the fault messages M2 and M1 sorted according to the prioritization in step 31, whereby the fault message M2 is prioritized here as an example due to the stored subsequent fault N and the impending fault chain C.

[0148] Such prioritization of fault messages M1 and M2 enables maintenance personnel to distinguish between relevant fault messages M with potentially high damage potential, less relevant fault messages M, and potentially already subsiding fault messages M, in order to process multiple simultaneously received fault messages M according to this prioritization. For each individual fault message M1 and M2, as explained above, the respective fault causes U and repair measures R can be output in the correspondingly determined fault cause sequence S1 or repair measure sequence S2. Reference symbol list 11 Analysis system 13 Interface 15 Ejector 17 Database 19 Control unit 21 Radio equipment 23 Receiver 24 Output device 25 Feedback device 27 Decoding device 29 Checks 31 Spend 33 Refrigeration system 35 Checks 37 liquefiers 39 evaporators 41 compressors 43 containers 45 Expansion valve 46 Shut-off or control valve 47 Management Step 49 50 steps Step 51 53 Suction port 55 steps Step 57 Step 59 Step 61 Step 63 65 steps Step 67 69 Interface 71 Radio equipment 73 Temperature sensor 75 Pressure sensor Issue 77 79 Control unit 81 Control line An alarm message B Weighting factor C. Disruption chain Real-time data G1 Total number of faults G2 Number of fault causes G3 Repair count K1 Customer-specific cause of fault K2 plant-specific repair measure M Fault message M1 fault message M2 fault message R repair measure R1 Repair Measure R2 repair measure R3 repair measure R4 repair measure S1 Sequence of Fault Causes S2 Repair sequence U cause of malfunction U1 Fault cause U2 Fault Cause U3 Fault Cause U4 Fault cause W1 Probability of fault causes W2 Repair success probability

Claims

[1] Methods for analyzing malfunctions of refrigeration systems (33) and / or building technology systems, comprising the steps: - Receiving a fault message (M, M1, M2) from a refrigeration system (33) or a building technology system; - Determining one or more of the fault causes (U, U1, U2, U3, U4) associated with the received fault message (M, M1, M2) from a database (17); - for each of the identified causes of disturbance (U, U1, U2, U3, U4): - Determining the probability of the cause of the disturbance (W1) assigned to each of the respective disturbance causes (U, U1, U2, U3, U4) as well as - Determining one or more repair measures (R, R1, R2, R3, R4, R5) assigned to the respective cause of the fault (U, U1, U2, U3, U4) from the database (17); - for each of the repair measures (R, R1, R2, R3, R4, R5) assigned to the respective cause of the fault (U, U1, U2, U3, U4): - Determining a repair success probability (W2) assigned to each repair measure (R, R1, R2, R3, R4, R5); and - Outputting the identified causes of malfunction (U, U1, U2, U3, U4) together with the respective assigned repair measures (R, R1, R2, R3, R4, R5), whereby the causes of malfunction (U, U1, U2, U3, U4) are output in a sequence (S1) according to the identified probabilities of the causes of malfunction (W1) and whereby the repair measures (R, R1, R2, R3, R4, R5) assigned to a respective cause of malfunction (U, U1, U2, U3, U4) are output in a sequence (S1) according to the identified probabilities of repair success (W2). [2] Method according to claim 1, wherein the fault message (M, M1, M2) is encoded in an alarm message (A) which is received, wherein the fault message (M, M1, M2) is decoded from the received alarm message (A). [3] Method according to claim 2, wherein the decoding of the fault message (M, M1, M2) is carried out by a text AI (artificial intelligence). [4] Method according to any of the preceding claims, wherein the fault message (M, M1, M2) includes information about a location of the fault. [5] Method according to one of the preceding claims, wherein the probability of the cause of the fault (W1) is determined as a conditional probability given a fault message (M, M1, M2). [6] Method according to any of the preceding claims, wherein the probability of the cause of the fault (W1) and / or the probability of the success of the repair (W2) is calculated. [7] Method according to any one of the preceding claims, where the probability of the cause of the disturbance (W1) is determined as a frequency-based probability of the cause of the disturbance (W1) based on the frequency of occurrence of the respective cause of the disturbance (U, U1, U2, U3, U4), wherein to determine the frequency-based fault cause probability (W1) a total number (G1) of fault events assigned to the respective fault message (M, M1, M2) and a fault cause number (G2) of events from the database (17) are determined, in which the respective fault cause (U, U1, U2, U3, U4) is assigned to the respective fault message (M, M1, M2), where the frequency-based probability of each fault cause (U, U1, U2, U3, U4) is determined as the ratio between the number of fault causes (G2) and the total number of faults (G1). [8] Method according to any one of the preceding claims, wherein the fault causes (U, U1, U2, U3, U4) include at least one plant-specific fault cause (K1), wherein the plant-specific fault cause (K1) is issued exclusively upon receipt of the fault message (M, M1, M2) from a specific refrigeration system (33) and / or building technology system; and / or where the plant-specific fault cause (K1) is only issued upon receipt of a request from a specific plant operator for the fault causes (U, U1, U2, U3, U4) and the repair measures (R, R1, R2, R3, R4, R5) assigned to the fault message (M, M1, M2). [9] Method according to claim 8, wherein, in addition to the plant-specific fault cause (K1), a plant-specific fault cause probability is determined that is increased compared to the determined frequency-based fault cause probability (W1). [10] Method according to claim 9, wherein to determine the plant-specific fault cause probability, the frequency-based fault cause probability (W1) is first determined on the basis of the number of fault causes (G2) assigned to the plant-specific fault cause (K1) and the total number of fault messages (G1), and wherein the frequency-based fault cause probability (W1) is multiplied by a weighting factor (B) greater than 1. [11] Method according to one of the preceding claims, wherein the repair success probability (W2) is determined as a conditional probability given a given cause of the fault (U, U1, U2, U3, U4). [12] Method according to claim 11, wherein the fault message (M, M1, M2) is taken into account as a given condition when determining the conditional probability. [13] Method according to any one of the preceding claims, wherein the repair success probability (W2) is determined as a frequency-based repair success probability (W2), wherein to determine the frequency-based repair success probability (W2) a fault cause number (G2) of events that are assigned to the respective fault cause (U, U1, U2, U3, U4) as well as a repair number (G3) of repair events are determined from the database (17) in which the respective repair measure (R, R1, R2, R3, R4, R5) is assigned to the respective fault cause (U, U1, U2, U3, U4), where the frequency-based repair success probability (W2) of the respective repair measure (R, R1, R2, R3, R4, R5) is determined as the ratio between the number of repairs (G3) and the number of fault causes (G2). [14] Method according to any one of the preceding claims, wherein the repair measures (R, R1, R2, R3, R4, R5) include at least one plant-specific repair measure (K2), wherein the plant-specific repair measure (K2) is issued exclusively upon receipt of the fault message (M, M1, M2) from a specific refrigeration system (33) and / or building technology system; and / or where the plant-specific repair measure (K2) is issued exclusively upon receipt of a request from a specific plant operator for the fault causes (U, U1, U2, U3, U4) and the repair measures (R, R1, R2, R3, R4, R5) associated with the fault message (M, M1, M2). [15] Method according to claim 14, wherein, in addition to the plant-specific repair measure (K2), a plant-specific repair success probability is determined that is increased compared to the frequency-based repair success probability (W2). [16] Method according to claim 15, wherein to determine the plant-specific repair success probability, the frequency-based repair success probability (W2) is first determined on the basis of the number of repairs (G3) and the number of fault causes (G2) assigned to the plant-specific repair measure (K2), and wherein the frequency-based repair success probability (W2) is multiplied by a weighting factor (B) greater than 1. [17] A method according to any of the preceding claims, wherein fault causes (U, U1, U2, U3, U4) and / or repair measures (R, R1, R2, R3, R4, R5) are added to the database (17), wherein an added fault cause (U, U1, U2, U3, U4) is initially assigned a fault cause probability (W1) of one and / or wherein an added repair measure (R, R1, R2, R3, R4, R5) is initially assigned a repair success probability (W2) of one, wherein the fault cause probability (W1) of the added fault cause (U, U1, U2, U3, U4) and / or the repair success probability (W2) of the added repair measure (R, R1, R2, R3, R4, R5) are subsequently, upon receipt of a fault message (M, M1, M2), based on a relative frequency of occurrence of the added The cause of the fault (U, U1, U2, U3, U4) or the added repair measure (R, R1, R2, R3, R4, R5) will be determined. [18] Method according to any one of the preceding claims, where, after a fault has been rectified, information (I) about an actual cause of the fault (U, U1, U2, U3, U4) and information (I) about a successful repair measure (R, R1, R2, R3, R4, R5) are received, wherein the information (I) about the actual cause of the fault (U, U1, U2, U3, U4) and the information (I) about the successful repair measure (R, R1, R2, R3, R4, R5) are stored in the database (17), in particular as a fault event assigned to the cause of the fault (U, U1, U2, U3, U4) in the received fault message (M, M1, M2) and / or as a repair event assigned to the repair measure (R, R1, R2, R3, R4, R5) in the actual cause of the fault (U, U1, U2, U3, U4). [19] Method according to any of the preceding claims, wherein real-time data (E) from the refrigeration system (33) or the building technology system are received. [20] Method according to claim 19, wherein the received real-time data (E) are taken into account when determining the sequence of fault causes (S1) and / or the sequence of repair measures (S2), in particular wherein the fault cause probabilities (W1) and / or the repair success probabilities (W2) are determined as a function of the received real-time data (E). [21] Method according to claim 19 or 20, wherein the determined fault cause probabilities (W1) and / or the determined repair success probabilities (W2) are adjusted depending on the received real-time data (E), in particular multiplied by a weighting factor. [22] Method according to any one of claims 19 to 21, wherein fault causes (U, U1, U2, U3, U4) and / or repair measures (R, R1, R2, R3, R4, R5) are excluded based on the received real-time data (E), and / or wherein fault causes (U, U1, U2, U3, U4) and / or repair measures (R, R1, R2, R3, R4, R5) are prioritized and output based on the received real-time data (E). [23] Method according to any one of claims 19 to 22, wherein the real-time data (E) comprise a pressure, a pressure change, a temperature, a temperature change, a valve opening degree, a control setpoint, a device identification, further fault messages (M, M1, M2) of the refrigeration system (33) or the building technology system and / or a fault message (M, M1, M2) of a further refrigeration system (33) or further building technology system arranged at an installation location of the refrigeration system (33) or the building technology system. [24] Method according to any one of claims 19 to 21, wherein multiple fault messages (M, M1, M2) are received, wherein the fault messages (M, M1, M2) are prioritized on the basis of the received real-time data (E). [25] Method according to claim 24, wherein decaying faults are detected using the real-time data (E), wherein fault messages (M, M1, M2) for decaying faults are given lower priority, and wherein, for decaying fault messages (M, M1, M2), instead of the fault causes (U, U1, U2, U3, U4, U3) and repair measures (R, R1, R2, R3, R4, R5), in particular information about the decay of the fault is output. [26] Method according to one of the preceding claims, wherein multiple fault messages (M, M1, M2) are received and wherein the fault messages (M, M1, M2) are prioritized on the basis of expected fault chains (C) which represent a probability of the occurrence of a subsequent fault (N). [27] Method according to claim 26, wherein received real-time data (E) are taken into account when determining the expected disturbance chains (C). [28] Method according to claim 26 or 27, wherein, in the event of a subsequent fault (N) occurring as a result of a fault message (M, M1, M2), information about the occurrence of the subsequent fault (N) is stored in the database (17). [29] Method according to one of claims 26 to 28, wherein a prediction of the occurrence of a chain of faults (C) after receiving the fault message (M, M1, M2) is determined on the basis of information stored in the database (17) relating to subsequent faults (N). [30] Analysis system (11) for analyzing malfunctions of a refrigeration system (33) and / or a building technology system, comprising - an interface (13) at which fault messages (M, M1, M2) from the refrigeration system (33) or the building technology system can be received, - a database (17) in which fault causes (U, U1, U2, U3, U4) and repair measures (R, R1, R2, R3, R4, R5) are stored, - a control unit (19) which is connected to the interface (13) and the database (17), and - an output device (24), wherein the control device (19) is designed to: - to identify one or more fault causes (U, U1, U2, U3, U4) associated with a received fault message (M, M1, M2) from the database (17); - for each of the identified causes of disturbance (U, U1, U2, U3, U4): - one fault cause probability (W1) assigned to the respective fault cause (U, U1, U2, U3, U4) as well as - to determine one or more repair measures (R, R1, R2, R3, R4, R5) from the database (17) that are assigned to the respective cause of the fault (U, U1, U2, U3, U4); - for each of the repair measures (R, R1, R2, R3, R4, R5) assigned to the respective cause of the fault (U, U1, U2, U3, U4): - to determine a repair success probability (W2) assigned to each repair measure (R, R1, R2, R3, R4, R5); - to sort the fault causes (U, U1, U2, U3, U4) in a fault cause sequence (S1) according to the determined fault cause probabilities (W1) and to sort the repair measures (R, R1, R2, R3, R4, R5) assigned to each fault cause (U, U1, U2, U3, U4) in a repair measure sequence (S2) according to the determined repair success probabilities (W2); and - to transmit the identified fault causes (U, U1, U2, U3, U4) according to the fault cause sequence (S1) and the assigned repair measures (R, R1, R2, R3, R4, R5) according to the repair measures sequence (S2) to the output device (24), wherein the output device (24) is designed to output the fault causes (U, U1, U2, U3, U4) according to the fault cause sequence (S1) and the repair measures (R, R1, R2, R3, R4, R5) assigned to each fault cause (U, U1, U2, U3, U4) according to the repair measures sequence (S2). [31] Analysis system (11) according to claim 30, wherein the fault message (M, M1, M2) is encoded in an alarm message (A), wherein the alarm message (A) is receivable at interface (13), and wherein the control device (19) is configured to decode the fault message (M, M1, M2) from the received alarm message (A), in particular by means of a text AI. [32] Analysis system (11) according to claim 30 or 31, further comprising an interface (13) for receiving real-time data (E) from the refrigeration system (33) or the building technology system. [33] Analysis system (11) according to one of claims 30 to 32, further comprising a feedback device (25) for reporting an actual cause of fault (U, U1, U2, U3, U4) and a successful repair measure (R, R1, R2, R3, R4, R5).

Images