Patent Application
20220198392
The present disclosure relates to the automation of industrial service applications and, in particular, to an arrangement for supporting service transactions among connected devices in an industrial system.
The advent of Internet-of-Things (IoT) connectivity and autonomous industrial systems may disruptively increase figures-of-merits such as productivity, quality, robustness and consistency of the output in the near future. At the same time, this development brings about new challenges in terms of device and transaction management. Available management solutions are not designed for—and may not adequately support—the multiplication of direct (ad-hoc, machine-to-machine) interactions of numerous networked devices in an industrial system. These shortcomings may be felt as lacking scalability, transparency and performance.
The available solutions are typically highly centralized and rigid. For example, a fleet of robots is programmed to carry out a certain task, controlled and supervised by a central management system. A change in the task requires the reprogramming of the robots. While this paradigm currently works well, a different approach will be needed in the future when numerous flexible IoT devices from various manufacturers are allowed to interact in a largely autonomous manner. Most management systems in use today do not offer the scalability and interoperability required in such a scenario.
One objective of the present disclosure is to enable the direct execution of automated services among machines. Another objective is to provide a medium allowing the parties to share and maintain their service conditions, service contracts, and transaction history in a scalable and transparent manner. A further objective is to propose a method of performing a service transaction in an industrial system.
These and other objectives are achieved by the invention according to the independent claims. The dependent claims are directed to advantageous embodiments of the invention.
According to a first aspect of the invention, there is provided a distributed ledger (DL) arrangement for supporting service transactions in an industrial system. The arrangement comprises a plurality of nodes of a network, each configured to maintain a distributed ledger copy. It further comprises a plurality of machine-to-ledger interfaces and one or more manager-to-ledger interfaces. Each machine-to-ledger interface is configured to receive, from a device acting as service provider and/or service consumer in the industrial system, service condition inquiries and requests to record transactions in the DL. Each manager-to-ledger interface is configured to receive, from a device owner authorized to specify service conditions with effect on the devices, requests to record service conditions in the DL.
A novel and non-obvious application of blockchain technology, the DL arrangement according to the first aspect can act as an enabler for a high degree of automation in industrial service applications. This may result in faster and less costly execution in the industrial system that the DL arrangement supports. The near real-time recording of service transactions makes it possible for invested parties (e.g., companies) to see at all times how many services they have provided and consumed, which can be translated directly into financial performance numbers. Thus, detailed and up-to-date financial information is available at any time and is no longer restricted to slow channels such as quarterly statistics. Finally, the scalability and transparency of the DL arrangement have the potential to create new industrial IoT business opportunities.
More specifically, the transparency is achieved because a party (service provider and/or consumer) can inspect the ledger and get an up-to-date view on all relevant transactions. The scalability is made possible thanks to the absence of a central entity burdened with the management of an increasing number of devices. Interoperability is a consequence of all parties using the same DL arrangement to communicate and may do so in a coherent manner. Finally, performance increases since service providers and consumers can interact directly and via the DL in a largely automated manner. In general terms, the addition of a DL underpinning endows the industrial system with a scalable, auditable backbone for machine-to-machine transactions, enabling (business) monitoring in near real time at low cost.
According to a second aspect of the invention, there is provided a method of performing a service transaction in an industrial system supported by a DL. The method comprises the following steps, which may be overlapping in time and/or performed in a partially different order: in response to a request by an authorized device owner of a first device acting as service provider in the industrial system, recording a service condition relating to the first device in the distributed ledger; in response to a request by an authorized device owner of second device acting as service consumer in the industrial system, recording a service condition relating to the second device in the distributed ledger. These initial steps may be performed in a preliminary phase, separated in time from the subsequent steps and by different entities. The method further comprises: transferring a device-to-device message with a service request from the second device to the first device; processing a service condition inquiry to the distributed ledger, wherein the inquiry is from the first device and relates to a service condition with effect on at least the first device itself; transferring a device-to-device message with a service request reply from the first device to the second device; transferring a device-to-device message with a service order from the second device to the first device, wherein the ordered service is to be provided by the first device for the benefit of the second device. Here, the device-to-device messages need not pass through the DL but may be conveyed by a different communication medium. The method further comprises, in response to a request by the first device, recording a transaction corresponding to the ordered service in the distributed ledger.
The service transaction method according to the second aspect shares the advantages transparency, scalability, interoperability and/or excellent performance with the first aspect.
According to a third aspect of the invention, there is provided a method of operating a service-provider device in an industrial system supported by a DL. This method comprises: receiving a service request from a service-consumer device in the industrial system; submitting a service condition inquiry to the distributed ledger, wherein the inquiry relates to a service condition with effect on at least the device itself; sending a service request response to the service-consumer device; receiving a service order from the service-consumer device, wherein the ordered service is to be provided for the benefit of the service-consumer device; and submitting a request for recordation in the distributed ledger of a transaction corresponding to the ordered service.
This way of operating the service-provider device offers, like the first aspect of the invention, prominent transparency, scalability, interoperability and/or performance.
According to a fourth aspect, there is provided a computer program containing instructions for causing a computer—or in particular one or more devices in the industrial system—to carry out one of the above methods. The computer program may be stored or distributed on a data carrier. As used herein, a “data carrier” may be a transitory data carrier, such as modulated electromagnetic or optical waves, or a non-transitory data carrier. Non-transitory data carriers include volatile and non-volatile memories, such as permanent and non-permanent storage media of magnetic, optical or solid-state type. Still within the scope of “data carrier”, such memories may be fixedly mounted or portable.
As used in this disclosure, a “distributed ledger” (DL) may be a type of ledger that is shared, replicated, and synchronized in a distributed and decentralized manner. A DL may be understood as an instance of the architecture described in Technical Specification FG DLT D3.1 “Distributed ledger technology reference architecture” issued on 1 Aug. 2019 by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). The terminology of the present disclosure is intended to be coherent with the Technical Specification FG DLT D1.1 “Distributed ledger technology terms and definitions” issued on 1 Aug. 2019 by the same body.
The term “industrial system” may refer to an industrial production or manufacturing system, a centralized or distributed industrial control system, a mechanical or chemical processing system, an energy generation system, and other collections of interrelated industrial devices.
As used herein, furthermore, a “service condition” with effect on at least one device in the industrial system may include a permission to provide a service to another device in the industrial system, a permission to request a service from another device in the industrial system; a constraint on providing such service, a constraint on requesting such service (service constraint), a compensation schedule specifying the compensation to be paid by the service-consuming device to the service-providing device in exchange for a provided service; a balance of credits to be used for said compensation.
Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to “a/an/the element, apparatus, component, means, step, etc.” are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.
Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, on which:
The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, on which certain embodiments of the invention are shown. These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of invention to those skilled in the art. Like numbers refer to like elements throughout the description.
The left half of
As indicated on the plaques with double vertical edges in
The right-hand section of
Key characteristics of the DL include Append-Only (full transactional history is retained, no transactions and values are overwritten), Immutability (cryptographically secure and immutable, thereby tamper-proof and attestable), Shared (the ledger is shared among multiple nodes) and Distributed (ensuring scalability, wherein a larger number of nodes makes consensus protocol more resilient to attacks). A consensus mechanism of the DL includes rules and procedures by which the nodes 111 agree on validating transactions. Two categories of consensus process, both of which are potentially useful in implementations of the aspects disclosed herein when the DL arrangement 110 is permissionless, are proof of work (PoW) and proof of stake (PoS). In permissioned DL arrangements 110, which are considered to have more potential in (industrial) business applications, a more efficient approach may be to run a distributed agreement protocol among the well-defined permissioned parties. The fact that no single entity has the power to manage the DL arrangement 110 on its own is congenial with the autonomous behaviour of the IoT-connected devices SP1, R1, R2, TB1 of the industrial system 150 and promotes the objectives noted initially.
As shown in
As an optional feature in the case where the DL is of the permissioned or hybrid type, the machine-to-ledger interfaces 120 or manager-to-ledger interfaces 130, or both, are configured to restrict access to ledger data related to other devices or other device owners. In a permissioned DL, more precisely, only authorized nodes are maintaining the distributed ledger, and this makes it possible to restrict read access and to restrict who can issue transactions. This way, the DL arrangement 110 may apply privacy-preserving methods to protect user data, which enables parties to verify information pertaining to their activities without revealing detailed, potentially private information about transactions between other parties. Privacy-preserving methods exist for permissionless DL arrangements as well.
As briefly mentioned above, each of the service conditions may include a permission to provide a service to another device in the industrial system 150, a permission to request a service from another device in the industrial system 150; a constraint on providing such service, a constraint on requesting such service (service constraint), a compensation schedule specifying the compensation to be paid by the service-consuming device to the service-providing device in exchange for a provided service; an (optionally timestamped, dated) balance of credits to be used for said compensation. The balance may be an initial value applying at a specified point in time, i.e., before compensations have been exchanged with other devices of the industrial system 150.
A party A who/which acts as device owner or device manager can store service conditions on the DL, which describe an authorization list for each of its devices or device families. The party A may be a human operator, company, machine-learning agent, other stakeholder or stakeholder representative. Alternatively, the party A referred to herein may be a delegate who has been appointed by an original device owner. As an example of delegation, the original device owner may have ceded part of its authority (e.g., the authority to enter into agreements regarding service conditions) to a local controller associated with the device or to processing resources in the device itself. An authorization list may specify which devices or device families are authorized to request the service(s) of this device. Rather than merely specifying the binary information whether or not a device (or device family) is allowed to request a service, it can contain fine-grained access control with tunable compensation for its service:
On the consumer side, a party B (e.g., operator, company, machine-learning agent, other stakeholder or stakeholder representative) can store service constraints on the distributed ledger. In this disclosure including the claims, service constraints are understood as a special case of service conditions. The service constrains may also specify authorization lists for each device (or device family). By contrast, these authorization lists specify which services can be requested from which devices or device families and how much the device is allowed to invest, e.g., specifying the number of times it can request a service or how many credits it can spend in total. It is possible for party B to replenish the virtual investment capital by updating authorization lists in its service constraints.
Naturally, while in principle service conditions and service constraints enable detailed control, it is possible to specify fairly unrestricted access. In the simplest case, the same service may simply be offered by an entire device family, e.g., a certain class of robots, to any device at a fixed compensation. Likewise, a device may be allowed to request a service from certain devices without restrictions, e.g., when the corresponding parties have higher-level service-level agreements in place.
The DL arrangement 110 may further support so-called smart contracts, executing certain pieces of code directly in the distributed ledger and thereby pushing automation further. Accordingly, as shown in
Conceptually, the described components of the DL arrangement 110 may be considered to operate on top of the DL itself. The components allow parties to define dynamically adaptable service conditions for devices offering services and service constraints for devices consuming services. The devices then interact directly based on these conditions and constraints, and carry out the negotiated service actions. The transaction results are then again captured in the distributed ledger as a permanent record for the involved parties. In the DL, the transactions may be captured as a time-stamped list of activities. The activities may be chronologically sorted, sorted by device or by device owner. Information regarding the involved parties (device owners), service-provider devices and service-consumer devices is included in the DL. A transaction may optionally be signed by each involved party, to allow any third party to verify that the involved parties agreed to the transaction. In addition to the transactions, the DL may include up-to-date balances of credits for such devices which are involved in exchange of compensations; such balances may form part of service constraints in the sense explained above. The data structure to be used for the DL may be designed in view of requirements such as auditability, inspectability, robustness, read or write speed, traceability etc. and their relative weights in the use case at hand.
The industrial system 150 may optionally include a communications network 160 configured to transfer device-to-device messages. The communication network 160 may be at least partially independent of the distributed ledger arrangement as far as hardware, network infrastructure and/or execution is concerned. For example, the communication network 160 may be capable of transferring the device-to-device messages without passing via the DL. A device-to-device message may be a service request, a service request response, a service order, a service status report, a service completion report or combinations of these.
Similarly, device owner B stores its service constraints (a type of service condition) in the distributed ledger. The DL, in response to a request 220 by an authorized device owner B of second device devB acting as service consumer in the industrial system 150, recording a service condition relating to the second device in the distributed ledger.
A service request 230 concerning a service S is transferred from the second device devB. Either the service request 230 is recorded in the DL—which may support an auction-like bidding procedure as explained below—or the service request 230 is transferred as a device-to-device message directly to an intended service provider device devA, e.g., using the communication network 160.
Device devA acquires the latest service conditions, which device owner party A has had deposited in the DL, and the service constraints for party B, verifies their compatibility in the sense that devB is entitled to request service S. Accordingly, the DL processes a service condition inquiry 240 to the distributed ledger. The inquiry is from the first device devA and relates to a service condition with effect on at least the first device itself. Depending on the rules configured for the DL, the DL may accept to process service condition inquiries even if they relate to further devices than the inquiring one.
If the verification is successful 241, the first (service-provider) device devA sends the relevant parts to the second (service-consumer) device devB. Alternatively, it sends a pointer to the relevant parts in the distributed ledger to the second device devB so that the second device devB can obtain the information from the ledger itself. This may be achieved by transferring a device-to-device message with a service request reply 250 from the first device devA to the second device devB.
If the second device devB accepts the service condition 242, it sends a service order to the first device devA, which carries out the service. As shown in
At the end, the first and/or second devices devA, devB confirm the completion of the service action in the distributed ledger. The DL, in response to a request 280, records a transaction corresponding to the ordered service. If the request 280 for recordation is submitted by the first device devA, it may be conditional upon the first device devA having received a device-to-device message with a service status report 270 from the second device devB.
It is noted that the initial requests 210, 220 may be performed in a preliminary phase, which may be separate in time from the subsequent sequence of messages beginning with the service request 230. Similarly, the subsequent sequence of messages may be repeated without repeating the initial requests 210, 220; in other words, the service conditions deposited in the DL may apply for a large number of service transactions.
In a variation of the embodiment shown in
The present disclosure further provides a method of operating a service-provider device devA in an industrial system 150 supported by a distributed ledger 110. This method is illustrated in
As another example of an industrial system,
The topology shown in
As suggested by the three dotted frames in
The temporary awarding of command power (or control privileges) in the water pumping system 350 illustrates an important special case of service conditions and service constraints. Command power may correspond to a voluntary hierarchic relationship between two devices or device levels, which comes into being after the higher level has requested, from the lower level, permission to exert power over the lower level, and the lower level has granted such permission. A handshake procedure may be used to request and grant the command power. The data exchange between the higher and lower level may be documented by the DL arrangement 110, which may then be referred to as a watchdog. The current command power currently awarded in an industrial system may be indicated to operators or provided on request from the DL arrangement 110. The example of water transfer between reservoirs has already been mentioned. In another example, a maintenance agent may temporarily be granted command power over a water pumping station 390—in addition to the local operator interface 351 or in its stead—which is then returned after completion of the maintenance. The requesting, awarding and returning of the command power are all recorded in the DL arrangement 110.
The aspects of the present disclosure have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 20217169.0 | Dec 2020 | EP | regional |
