METHODS FOR AN AUTONOMOUS ROBOTIC MANUFACTURING NETWORK
20170307387 · 2017-10-26
Inventors
Cpc classification
Y02P90/02
GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
G05B19/4155
PHYSICS
International classification
Abstract
A computer-implemented method for operating a robotic manufacturing network, comprising: (a) providing a communications network; (b) providing a plurality of computer processor nodes for processing data wherein said computer processor nodes are participants on said communication network; (c) providing a plurality of manufacturing facilities; (d) providing a plurality of transport agents connecting said manufacturing facilities; (e) providing a plurality of actors selected from the group consisting of said manufacturing facilities and said transport agents wherein said actors are participants in said robotic manufacturing network and communicate on said communications network; (f) providing a robotic capability model as manufacturing supply chain planning service whereby autonomous manufacturing supply chain functionality is created that transforms product specifications into optimized manufacturing production plans thereby permitting products to be made by a population of networked manufacturing agents.
Claims
1. A computer-implemented method for operating a robotic manufacturing network, comprising: (a) providing a communications network; (b) providing a plurality of computer processor nodes for processing data wherein said computer processor nodes are participants on said communication network; (c) providing a plurality of manufacturing facilities which will: (i) receive manufacturing instructions; (ii) receive input materials and/or products; (iii) output products according to received manufacturing instructions; (d) providing a plurality of transport agents connecting said manufacturing facilities which will: (i) transport input materials to and from said manufacturing facilities; (ii) transport products to and from said manufacturing facilities; (e) providing a plurality of actors selected from the group consisting of said manufacturing facilities and said transport agents wherein said actors are participants in said robotic manufacturing network and communicate on said communications network; (f) providing a robotic capability model as manufacturing supply chain planning service which will: (i) execute on one or more of said computer processor nodes; (ii) receive requests for registration of robotic capabilities; (iii) receive requests for manufacturing plans to fulfill product specifications; (iv) transform product specification into manufacturing plans detailing manufacturing instructions relating steps of manufacture to capabilities which may be provided by one or more of said manufacturing facilities; (v) send replies with manufacturing plans for products specifications; and whereby autonomous manufacturing supply chain functionality is created that transforms product specifications into optimized manufacturing production plans thereby permitting products to be made by a population of networked manufacturing agents.
2. The computer-implemented method of claim 1, further providing: (g) a directory as service which will: (i) execute on one or more of said computer processor nodes; (ii) receive requests for registration and/or deregistration of said actors with associated capabilities; (iii) verify all requests for registration of said actors against said robotic capability model to ensure directory registered capabilities are compatible with capabilities registered in said robotic capability model; (iv) receive request for registration information about said actors; (v) reply by sending registration information about said actors; and whereby autonomous manufacturing supply chain functionality is augmented with the ability to broker individual execution steps of manufacturing plans through a directory service.
3. The computer-implemented method of claim 1, further providing: (h) a vehicle route planner as service which will: (i) execute on one or more of said computer processor nodes; (ii) receive routing requests to plan routes between two or more locations; (iii) reply to routing requests with routing plans; and whereby autonomous manufacturing supply chain functionality is augmented with the ability to optimize the execution steps of manufacturing plans and associated conveyance of materials and/or products.
4. The computer-implemented method of claim 1, further providing: (j) a consensus service for agreement of contracts which will: (i) execute on one or more of said computer processor nodes; (ii) maintain a distributed storage of information on contract agreements or a distributed ledger which is synchronized among peers participating in said consensus service through sending and receiving of synchronization messages; (iii) receive proposals for addition to information and/or changes to information in said global ledger; (iv) send and/or receive messages to negotiate agreement about acceptance or refusal of such proposals; (v) record the outcome of agreement and/or refusal of such proposals in said global ledger; and whereby autonomous manufacturing supply chain functionality is augmented with peer-to-peer contract agreement for individual execution steps of manufacturing production plans and/or associated conveyance of material and/or products.
5. The computer-implemented method of claim 1, further providing: (k) a certificate service for authentication which will: (i) execute on one or more of said computer processor nodes; (ii) receive requests for authentication; (iii) send authentication acknowledgements; or (iv) send authentication refusals; and whereby access to said directory is secured and non-repudiation is offered to secure information in said directory.
6. The computer-implemented method of claim 1, wherein said robotic capability model further will: receive requests to retrieve robot capability specifications; send replies with robot capability specifications; and whereby access to robot capability specifications is enabled for human operators and client software programs.
7. The computer-implemented method of claim 1, wherein said vehicle route planner further will: receive notifications of availability of said actors; and/or receive notifications of position of said actors; and/or receive notifications of schedule of said actors; whereby route optimization of whole fleets is enabled.
8. The computer-implemented method of claim 1, wherein said consensus service further will maintain information about contract execution feedback in said distributed storage of state information or a distributed ledger, whereby said consensus service enables real-time quality control feedback which can further be used in manufacturing plan optimization.
9. The computer-implemented method of claim 1, wherein said consensus service further will maintain information about contract payment in said distributed storage of state information or a distributed ledger, whereby said consensus service enables real-time payment for contract fulfillment.
10. The computer-implemented method of claim 1, wherein said manufacturing facilities are grouped into local manufacturing clusters and said transport agents are specialized into groups of local transport agents connecting said manufacturing facilities within local clusters and into groups of long distance transport agents inter-connecting local clusters and wherein manufacturing capabilities are duplicated between local manufacturing clusters whereby an inter-network of manufacturing clusters is formed and manufacturing plans are optimized for local manufacture deriving a productivity multiplier from rapid inter-operation of manufacturing facilities.
11. The computer-implemented method of claim 1, further providing (l) a geospatial reference service for mapping which will: (i) execute on one or more of said computer processor nodes; (ii) receive map updates; (iii) receive map reference data requests; (iv) reply to map reference data requests with map reference data; and wherein said vehicle route planner further will request and receive map reference data from said geospatial reference service to initialize the operation of said vehicle route planner whereby said vehicle route planner can outsource map reference data provision.
12. The computer-implemented method of claim 1, wherein said directory further will: receive notifications of availability of said actors; receive notifications of schedule of said actors; receive notifications of position of said actors; receive requests for information about availability of said actors; reply by sending availability information about said actors; receive requests for information about schedule of said actors; reply by sending schedule information about said actors; receive requests for information of position about said actors; reply by sending position information about said actors; and whereby said directory is extended from providing a registry of actors with specific capabilities to provide dynamic status information about actors which may be utilized by other clients or services.
13. The computer-implemented method of claim 1, wherein said actors further will: send notifications of registration and/or deregistration; send notifications of availability; send notifications of schedule; send notifications of position; and whereby said manufacturing facilities and transport agents are connected to said directory for querying of status of said manufacturing sites and said transport agents to enable brokerage of services and dynamic optimization of said vehicle route planner.
14. The computer-implemented method of claim 1, further providing: (m) one or more manufacturing proxies which will: (i) receive manufacturing instructions and relay them to a manufacturing agent; (ii) receive input materials and/or products and relay them to a manufacturing agent; (iii) receive and forward products made by a manufacturing agent according to received manufacturing instructions; and whereby non-robotic manufacturing facilities may be integrated and human manufacturers may function within said robotic manufacturing network.
15. The computer-implemented method of claim 1, further including one or more roads which will facilitate conveyance of materials and/or products.
16. The computer-implemented method of claim 1, further including one or more rail roads which will facilitate conveyance of materials and/or products.
17. The computer-implemented method of claim 1, further including one or more aerial corridors which will facilitate conveyance of materials and/or products.
18. The computer-implemented method of claim 1, further including one or more waterways which will facilitate conveyance of materials and/or products.
19. The computer-implemented method of claim 1, further including one or more tubular transport system which will facilitate conveyance of materials and/or products.
20. The computer-implemented method of claim 1, further including one or more floor routing systems which will facilitate conveyance of materials and/or products.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
[0016]
[0017]
[0018]
[0019]
[0020]
[0021]
[0022]
[0023]
[0024]
[0025]
[0026]
[0027]
[0028]
[0029]
[0030]
DETAILED DESCRIPTION
[0031] Referring to the diagram 100 of
[0032] Referring to the diagram 200 of
[0033] Referring to the diagram 300 of
[0034] Referring to the diagram 400 of
[0035] Referring to the diagram 500 of
[0036] Referring to the diagram 600 of
[0037] Referring to
[0038] Referring to
[0039] Referring to the diagram 900 of
[0040] Referring to the diagram 1000 of
[0041] Referring to the diagram 1100 of
[0042] Referring to the diagram 1200 of
[0043] Computing Environment of Services in the Supply Layer
[0044]
[0045] The described technology can be practiced in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network, such as a Local Area Network (“LAN”), Wide Area Network (“WAN”), or the Internet. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. Those skilled in the relevant art will recognize that portions of the described technology may reside on a server computer, while corresponding portions reside on a client computer (e.g., PC, mobile computer, tablet, or smart phone). Data structures and transmissions of data particular to aspects of the technology are also encompassed within the scope of the described technology.
[0046] Referring to
[0047] The input devices 1340 may include a keyboard and/or a pointing device such as a mouse. Other input devices are possible. The storage devices 1350 may include any type of computer-readable media that can store data accessible to the computer, such as magnetic hard and floppy disk drives, optical disc drives, magnetic cassettes, tape drives, flash memory cards, digital video disks (DVDs), Bernoulli cartridges, RAMs, ROMs, smart cards, etc. Indeed, any medium for storing or transmitting computer-readable instructions and data may be employed, including a connection port to a node on a network, such as LAN, WAN, or the Internet (not shown in
[0048]
[0049] Supply Chain Model Overview
[0050] The implementation of the described technology is described in terms of the Communicating Sequential Processes (CSP) computer language. As a mathematical model of process, CSP can be used to specify the methods of processes in a mathematical way, without ambiguity. The model checker Failures-Divergences Refinement (FDR) is then used to analyze and demonstrate properties of those methods.
[0051] As implemented by the described technology, we define the Supply Chain Interconnection Model (SCIM) in terms of abstraction layers that characterize and standardize the interaction functions of the autonomous supply chain. The Supply Chain Interconnection Model coexists with and relates to the OSI Model of the Internet. It is separate from the OSI model, because its domain is manufacturing rather than telecommunications. We define the following layers of the Supply Chain Interconnection Model, beginning at the bottom; these will be elaborated herein as: Transport Layer; Agent Layer; Artifact Layer; and Supply Layer.
[0052] The Supply Chain Interconnection Model (SCIM) proposed here derives its productivity multiplier from labor micro specialization in the agent layer, the relative collocation of collaborating agents in the transport layer and their swift and continual inter-operation as directed by the supply layer. We term the design concepts underpinning this productivity multiplier the SCIM Tenets of Productivity Multiplication. Please refer to
[0053] As a consequence of the pull-strategy model, the supply chain operates decoupled from traditional product ownership that is characteristic of present day “brand name” product marketing and push-strategy marketing. This enables end-user customizable products at essentially little or no additional costs compared to non-customized products. Please refer to
[0054] While robotic agents are assumed, nothing about the design inherently precludes human agents. As long as human agents 250 integrate into the framework, they may function within it; please refer to
[0055] Further, because of the narrow specialization of labor and the uniform interface for all agents, it is envisaged that smaller businesses, who presently find themselves locked out of a largely global supply chain, may find niche markets in this model. Internet users will find this a familiar theme. Where newspapers and television channels used to dominate information dissemination, today even small bloggers can publish and have a voice.
[0056] Therefore, while at first glance human operators and small businesses may fear themselves deprecated, the model presented here CREATES OPPORTUNITY FOR THE LOCAL SUPPLY CHAIN TO COMPETE once more. Finally, traditional “push-strategy” manufacturers may OUTSOURCE PARTS OF THEIR MANUFACTURING SUPPLY CHAIN INTO THE “CLOUD,” by delegating parts of their manufacture to Supply Chain Interconnection Model embedded manufacturing facilities. We term this “MANUFACTURING CLOUD SOURCING,” inspired by the concepts of outsourcing and cloud computing.
[0057] In various embodiments, the Supply Chain Interconnection Model (SCIM) relates the different operational aspects of the Autonomous Supply Chain including a supply layer, an artifact layer, an actor layer, and a transport layer to each other and to the OSI model of the internet.
[0058] Supply Chain Interconnection Model Definition
[0059] The Supply Chain Interconnection Model (SCIM) is defined in terms of the process calculus CSP. The model defines the behavior and interaction between architectural layers in the model as well as services and agents within layers of the model.
TABLE-US-00001 TABLE 1 Supply Chain Interconnection Model expressed as CSP model ------------------------------------------ -- THE SUPPLY CHAIN INTERCONNECTION MODEL ------------------------------------------ SCIM = (( ACTORS -- Actors Layer [|{|TransportMediumAction|}|] -- composed with: TRANSPORTS -- Transports Layer ) [|{|ArtifactAction|}|] -- composed with: ARTIFACTS -- Artifacts Layer ) [|{|ActorMsg,CCFMAction,DIRMsg,GeoAction|}|] -- composed with: SUPPLY -- Supply Layer
[0060] The definition shown in Table 1 models the layered architecture shown in
[0061] The Supply Chain Interconnection Model is intended to be deployed in a clustered fashion, combining local manufacturing centers with a transport backbone to achieve system scalability through a combination of distributed and centralized functions.
[0062] Actors Layer Definition
[0063] The Actors layer is a composition of both manufacturing actors and mobile actors. Mobile actors are transport agents that convey parts, products and materials. Manufacturing actors are stationary work cells that make parts, products and materials. The interaction of manufacturing actors and mobile actors is defined in the TransporterAction event alphabet. This alphabet will be used in section [0083]. It is defined in table 16. The ACTORS layer is defined as shown in Table 2.
TABLE-US-00002 TABLE 2 ACTORS Layer expressed as CSP model ------------------------ -- ACTORS LAYER DEFINED ------------------------ ACTORS = ManufacturingActor -- manufacturing facilities [|{|TransporterAction|}|] -- composed with: MobileActor -- transport agents
[0064] Transport Layer Definition
[0065] The Transports layer is the unsynchronized parallel combination of geospatial media. This includes static manufacturing sites termed work cells. Other media are possible, such as waterways. The TRANSPORT layer is defined as shown in table 3.
TABLE-US-00003 TABLE 3 TRANSPORT Layer expressed as CSP model --------------------------- -- TRANSPORT LAYER DEFINED --------------------------- TRANSPORTS = Road ||| Rail ||| ArialCorridor ||| WorkCell
[0066] Artifacts Layer Definition
[0067] Artifacts are things that are made. This includes physical artifacts, non-physical artifacts and meta artifacts. These are explained in section [0086]. The ARTIFACTS layer is defined as shown in table 4.
TABLE-US-00004 TABLE 4 ARTIFACTS Layer expressed as CSP model -------------------------- -- ARTIFICT LAYER DEFINED -------------------------- ARTIFACTS = PhysicalArtifact ||| NonPysicalArtifact ||| MetaArtifact
[0068] Supply Layer Definition
[0069] The SUPPLY layer accommodates the core functions of the Supply Chain Interconnection Model and coordinates the other layers. The SUPPLY layer is explained in section [0090]. The SUPPLY layer is defined as shown in table 5.
TABLE-US-00005 TABLE 5 SUPPLY Layer expressed as CSP model ------------------------ -- SUPPLY LAYER DEFINED ------------------------ SUPPLY = CCFM -- Consensus Contract-And- -- Feedback Model [|{|CertAct,CCFMAction|}|] -- composed with: ( GEO -- Geopatial Model [|{|GeoActionRef|}|] -- composed with: ( VRP -- Vehicle-Routing & -- Fleet-Optimization Model [|{|DIRMsg|}|] -- composed with: ( CERT -- Certificate & Security Model [|{|CertAct|}|] ( DIR -- Directory Services Model [|{|RCMMsg,RCMReq|}|] RCM -- Robotic Capability Model ) ) ) )
[0070] Emergent Property Invariants
[0071] Crucially, CSP allows us to reason about the complex interaction of processes and behaviors. This means properties of the model may be warranted through what CSP calls assertions. A successful assertion in the model checker FDR discharges mathematical proof of the correctness of the model. Please refer to tables 6 through 9 for guarantees of correctness of the Supply Chain Interconnection Model. These are discharged in
TABLE-US-00006 TABLE 6 Emergent Properties expressed as CSP model -- Emerging properties are behaviors that arise out of the -- composition of processes and their individual behaviors. -- Here we stipulate emergent properties of the Supply Chain -- Interconnection Model and its architectural layers. -- The system as a whole must not deadlock, diverge (livelock) -- or be non deterministic. Livelock occurs in unguarded recursion. -- We stipulate that unguarded recursion must not exist in system. assert SCIM :[deadlock free] assert SCIM :[livelock free] assert SCIM :[deterministic] -- The Supply layer is deadlock and livelock free but principally -- exhibits non-determinism based on interaction with the -- Certificate & Security Model Individual actions may be refused -- where authorization is declined. Therefore we require the -- “SUPPLY is deterministic” assertion to be false. assert SUPPLY :[deadlock free] assert SUPPLY :[livelock free] assert not SUPPLY :[deterministic]
TABLE-US-00007 TABLE 7 Emergent Properties expressed as CSP model continued -- The Actors layer are deadlock and livelock free but principally -- exhibits non-determinism. For example an actor may choose to self -- service, i.e. a robot may elect to charge itself when energy -- reserves are depleted. Therefore we require the “ACTORS is -- deterministic” assertion to be false. assert ACTORS :[deadlock free] assert ACTORS :[livelock free] assert not ACTORS :[deterministic] -- Artifacts are expected to be deadlock free, -- livelock free and deterministic. assert ARTIFACTS :[deadlock free] assert ARTIFACTS :[livelock free] assert ARTIFACTS :[deterministic] -- Transports is an unsynchronized parallel combination -- of geospatial models. As such, we expect the combination -- to be deadlock free, non diverging but not deterministic. -- This arises because each process in the TRANSPORTS model -- engages in fundamentally the same events but potentially -- with staggered progression. assert TRANSPORTS :[deadlock free] assert TRANSPORTS :[livelock free] assert not TRANSPORTS :[deterministic]
[0072] Discharging Mathematical Proof using a Model Checker
[0073] FDR permits us to verify CSP assertions through machine-checked proof. Please refer to
[0074] It is noted that the proofs discharged by FDR in
[0075] Model Behavior Invariants
[0076] In addition to emergent properties, specific properties of individual actors may be verified. Table 8 shows examples of constraints, which may be enforced through what CSP terms “trace and failure refinement.” Please refer to section [0082] for details of the Actors Layer.
TABLE-US-00008 TABLE 8 Specific Property Invariants expressed as CSP model ---------- Specific Property Invariants ----------------------------- -- In addition to emergent properties of the system as a whole, we -- may stipulate specific behavior invariants -- Here we stipulate that all actors must register. -- We achieve this simply by asserting trace refinement -- of the projections of all our actors to -- the “must register specification.” MUSTREGISTER = ActorMsg.register −> MUSTREGISTER assert MUSTREGISTER [T= Actor |\ {ActorMsg.register} assert MUSTREGISTER [T= MobileActor |\ {ActorMsg.register} assert MUSTREGISTER [T= ManufacturingActor |\ {ActorMsg.register} -- We may also stipulate abstraction and refinement constraints. -- For example a ManufacturingActor is an Actor. A MobileActor -- is an Actor. The behavior of both must therefore refine -- the behavior of Actor. We stipulate this in terms of -- Trace and Failure refinement using algebraic event hiding. ------ Specification ----- Implementation assert Actor [T= ManufacturingActor \ {|ManufactureReq,TransporterAction,ArtifactAction|} assert Actor [F= ManufacturingActor \ {|ManufactureReq,TransporterAction,ArtifactAction|} ------ Specification ----- Implementation assert Actor [T= MobileActor \ {|TransportReq,TransporterAction,TransportMediumAction|} assert Actor [F= MobileActor \ {|TransportReq,TransporterAction,TransportMediumAction|}
[0077] Transports Layer Elaboration
[0078] The Transports Layer is a physical layer which represents both fixed manufacturing sites as well as physical routes along which transport might take place: roads, rail & aerial corridors. The primary input of this layer into the model is geospatial reference data.
[0079] The transport layer defines this reference data in a manner that route planning and route optimization algorithms may consume it. There are many candidate implementations. One suggested implementation is through representation of geographic objects in an open source, object-relational database system. Scalability of this implementation to a national wide system can be either through “database sharding” or through interfacing to a “big data” system. Reference data may be sourced from freely editable maps of the World Relevant open source implementations accommodate open source routing solutions.
[0080] While the above implementation is but one possible configuration, characteristic of the Transport Layer is a geospatial database that interfaces to a routing optimization solution. The CSP definition of the Transport Layer is given in tables 9 through 13.
TABLE-US-00009 TABLE 9 Transport Model Defined expressed as CSP model ------ Transport Model Event Alphabet ------ datatype TransportMediumType = travel | park | occupy | reference datatype TransportType = RoadType | RailType | ArialType channel TransportMediumAction : TransportMediumType ------ Transport Process Model ------ TransportModel = let Geospatial(UNMAPPED) = GeoAction.map -> Geospatial(MAPPED) Geospatial(MAPPED) = TransportMediumAction.travel -> Geospatial(MAPPED) [ ] TransportMediumAction.park -> Geospatial(MAPPED) [ ] TransportMediumAction.occupy -> Geospatial(MAPPED) within Geospatial(UNMAPPED) ------ Invariant ------------------ assert TransportModel :[deadlock free]
[0081] In Table 9 we define the event alphabet of the transport layer and the core states and events of an abstract transport medium. In tables 10 through 13 we refine the model for “Road,” “Rail,” “ArialCorridor,” and “WorkCell.”
TABLE-US-00010 TABLE 10 Road Transport Model expressed as CSP model -- Road refines TransportModel Road = let Geospatial(UNMAPPED) = GeoAction.map -> Geospatial(MAPPED) Geospatial(MAPPED) = TransportMediumAction.travel -> Geospatial(MAPPED) [ ] TransportMediumAction.park -> Geospatial(MAPPED) within Geospatial(UNMAPPED) assert TransportModel \{|TransportMediumAction.occupy|} [T= Road assert TransportModel \{|TransportMediumAction.occupyl|} [FD= Road
TABLE-US-00011 TABLE 11 Rail Transport Model expressed as CSP model -- Rail refines TransportModel Rail = let Geospatial(UNMAPPED) = GeoAction.map -> Geospatial(MAPPED) Geospatial(MAPPED) = TransportMediumAction.travel -> Geospatial(MAPPED) [ ] TransportMediumAction.park -> Geospatial(MAPPED) within Geospatial(UNMAPPED) ------ Specification ----- Implementation assert TransportModel \{|TransportMediumAction.occupy|} [T= Rail assert TransportModel \{|TransportMediumAction.occupy|} [FD= Rail
TABLE-US-00012 TABLE 12 ArialCorridor Transport Model expressed as CSP model -- ArialCorridor refines TransportModel ArialCorridor = let Geospatial(UNMAPPED) = GeoAction.map -> Geospatial(MAPPED) Geospatial(MAPPED) = TransportMediumAction.travel -> Geospatial(MAPPED) within Geospatial(UNMAPPED) ------ Specification ----- Implementation assert TransportModel \{|TransportMediumAction.occupy,TransportMediumAction.park|} [T= ArialCorridor assert TransportModel \{|TransportMediumAction.occupy,TransportMediumAction.park|} [FD= ArialCorridor
TABLE-US-00013 TABLE 13 WorkCell Transport Model expressed as CSP model -- WorkCell refines TransportModel WorkCell = let Geospatial(UNMAPPED) = GeoAction.map -> Geospatial(MAPPED) Geospatial(MAPPED) = TransportMediumAction.occupy -> Geospatial(MAPPED) [ ] TransportMediumAction.park -> Geospatial(MAPPED) within Geospatial(UNMAPPED) ------ Specification ----- Implementation assert TransportModel \{|TransportMediumAction.travel|} [T= WorkCell assert TransportModel \{|TransportMediumAction.travel|} [FD=WorkCell
[0082] Actors Layer Elaboration
[0083] The Actors Layer represents stationary and mobile actors, both human and robotic. Actors are entities performing actions and as actors are capable of communicating with other entities in the system. Mobile actors will primarily perform the function of transporting artifacts in the system. Stationary actors will primarily perform manufacturing functions in the system. Together, stationary and mobile actors create a networked system. The actors layer relates to the OSI model for communication with other layers. In tables 14 and 15 we define the Actor model.
TABLE-US-00014 TABLE 14 Actor Event Alphabets expressed as CSP model -- Types of Actors datatype ActorType = Mobile | Stationary -- Status of the Actor in the Directory datatype DirectoryStatus = REG | UNREG | AVAILABLE | UNAVAILABLE -- Actors receive requests (ActorReqType) and emit messages (ActorMsgType) datatype ActorReqType = get_type | get_schedule | get_position | get_status datatype ActorMsgType = schedule | position | avail | register | deregister | unavail datatype ActorTypeType = type -- Channels that Actors sychronize on channel ActorReq : ActorReqType channel ActorMsg : ActorMsgType channel service channel ActorWhatType : ActorTypeType datatype ActorStatusType = READY | NOTREADY channel ActorStatus : ActorStatusType -- The Actor process alphabet as an enumerated set alphaActor = {|ActorReq,ActorWhatType,ActorMsg,ActorStatus,CCFMAction, DIRMsg,service |}
TABLE-US-00015 TABLE 15 Actor Definition expressed as CSP model -- Actor Definition Actor = let Directory(UNREG) = ActorMsg.register -> ActorStatus.NOTREADY -> (DIRMsg.ack -> Directory(UNAVAILABLE) [ ] DIRMsg.nack -> Directory(UNREG) ) Directory(UNAVAILABLE) = ActorMsg.avail -> (DIRMsg.ack -> ActorStatus.READY -> Directory(AVAILABLE) [ ] DIRMsg.nack -> ActorStatus.NOTREADY -> Directory(UNAVAILABLE) ) |~| ActorMsg.deregister -> (DIRMsg.ack -> ActorStatus.NOTREADY -> Directory(UNREG) [ ] DIRMsg.nack -> ActorStatus.NOTREADY -> Directory(UNAVAILABLE) ) Directory(AVAILABLE) = ( ActorReq.get_type -> ActorWhatType.type -> Directory(AVAILABLE) [ ] ActorReq.get_schedule -> ActorMsg.schedule -> (DIRMsg.ack -> Directory(AVAILABLE) [ ] DIRMsg.nack -> Directory(AVAILABLE) ) [ ] ActorReq.get_position -> ActorMsg.position -> (DIRMsg.ack -> Directory(AVAILABLE) [ ] DIRMsg.nack -> Directory(AVAILABLE) ) [ ] ActorReq.get_status -> ( ActorStatus.READY -> Directory(AVAILABLE) |~| ActorStatus.NOTREADY -> Directory(AVAILABLE) ) ) |~| service -> ActorStatus.NOTREADY -> Directory(UNAVAILABLE) |~| ActorMsg.deregister -> (DIRMsg.ack -> ActorStatus.NOTREADY -> Directory(UNREG) [ ] DIRMsg.nack -> ActorStatus.NOTREADY -> Directory(UNAVAILABLE) ) [ ] CCFMAction.propose -> ( CCFMAction.accept -> Directory(AVAILABLE) |~| CCFMAction.reject -> Directory(AVAILABLE) ) within Directory(UNREG) assert Actor :[deadlock free]
TABLE-US-00016 TABLE 16 Mobile Actor Definition expressed as CSP model ------------------------------------------------------ -- Transporter -- Mobile Transport Actor refines Actor || Transporter ------------------------------------------------------ datatype TransportReqType = do_move | do_deliver -- get_destination | get_eta channel TransportReq : TransportReqType datatype TransporterActionType = move | deliver | accept_deliver channel TransporterAction : TransporterActionType alphaTransporter = {|TransporterAction,TransportReq,ActorStatus,TransportMediumAction|} Transporter = let Directory(NOTREADY) = ActorStatus.READY -> Directory(READY) [ ] ActorStatus.NOTREADY -> Directory(NOTREADY) Directory(READY) = ActorStatus.NOTREADY -> Directory(NOTREADY) [ ] TransportReq.do_move -> TransportMediumAction.travel -> Directory(READY) [ ] TransportReq.do_deliver -- request to deliver -> TransportMediumAction.travel -> TransporterAction.deliver -- moving of goods -> TransporterAction.accept_deliver -- acceptance -> Directory(READY) within Directory(NOTREADY) MobileActor = Actor [alphaActor || alphaTransporter ] -- Alphabetised -- parallel Transporter -- composition ------ Specification ----- Implementation assert Actor [T= MobileActor \ {|TransportReq,TransporterAction,TransportMediumAction|} assert Actor [F= MobileActor \ {|TransportReq,TransporterAction,TransportMediumAction|}
[0084] Example technologies with which one might implement the Mobile Actor model are available today. In the United States, capabilities include air drone delivery services capable of carrying 5-Pound packages over 10 miles. In the United Kingdom, a robotic delivery service designed to handle local deliveries of goods has been announced. Both drones are examples of local mobile actors designed for local delivery. Long-haul drones are also appearing on the market. The United States recently saw eighteen-wheeler truck drones licensed for public road use as “autonomous heavy-duty truck.” The latter example pertains to the backbone mobile actor fleet concept of the SCIM deployment model while the former example pertains to the local mobile actor fleet concept of the SCIM deployment model.
[0085] What is missing from the discourse to date is a unified model for integrating mobile actors into a manufacturing supply chain. Our Actors model fills this void.
TABLE-US-00017 TABLE 17 Manufacturing Actor Definition expressed as CSP model ---------------------------------------------------- -- Manufacturer -- Manufacturing Actor refines Actor || Manufacturer ---------------------------------------------------- datatype ManufactureReqType = do_make channel ManufactureReq : ManufactureReqType alphaManufacturer = {|ManufactureReq,ArtifactAction,TransporterAction,ActorStatus|} Manufacturer = let Directory(NOTREADY) = ActorStatus.READY -> Directory(READY) [ ] ActorStatus.NOTREADY -> Directory(NOTREADY) Directory(READY) = ActorStatus.NOTREADY -> Directory(NOTREADY) [ ] TransporterAction.accept_deliver -> Directory(READY) [ ] ManufactureReq.do_make -> (ArtifactAction.fabricate -> Directory(READY) |~| ArtifactAction.craft -> Directory(READY) |~| ArtifactAction.grouping -> Directory(READY) |~| ArtifactAction.identify -> Directory(READY) ) within Directory(NOTREADY) ManufacturingActor = Actor [alphaActor || alphaManufacturer] Manufacturer ------------- Invariant ------------------ assert ManufacturingActor :[deadlock free]
[0086] Artifact Layer Elaboration
[0087] The Artifact Layer represents things that are made: “manufacturables” and “meta manufacturables.” Meta manufacturables are things that are made to assist in making other things. Meta manufacturables include means of identification: RFID tags, bar codes and QR codes. These are ancillary in the manufacturing process. Manufacturables are physical entities, parts or whole products. Manufacturables also include non-physical entities that are made: for example, a polish is made but is a non-physical entity. The ontology and calculus that composes physical and non-physical entities into coherent manufacturing plans that are actionable by robotic agents is defined separately in the patent “METHOD AND SYSTEM FOR AUTOMATED PRODUCT DESIGN AND OPTIMIZATION OF ROBOTIC MANUFACTURING SUPPLY-CHAINS.”
[0088] The aforementioned patent models relationships between different artifacts in an ontology that facilitates systematic product descriptions and relates those to robotic capabilities. The artifact model defined here in CSP concerns itself with the behavior of processes representing artifacts and their relationship with the Supply Chain Interconnection Model. The CSP artifact model is detailed in tables 18 and 19.
TABLE-US-00018 TABLE 18 Artifact Model Definition expressed as CSP model datatype ArtifactType = Manufacturable | MetaManufacturable datatype ManufacturableType = PhysicalEntity | NonPysicalEntity datatype ArtifactActionType = fabricate| craft | grouping | identify channel ArtifactAction : ArtifactActionType ArtifactModel = ArtifactAction.fabricate -> ArtifactModel -- fabricate as applied to physical materials [ ] ArtifactAction. craft -> ArtifactModel -- craft as applied to non physical manufacturables, -- for example “a shine” or “a polish” [ ] ArtifactAction.grouping -> ArtifactModel [ ] ArtifactAction.identify -> ArtifactModel
[0089] Artifacts are distinguished by their type and purpose. Physical artifacts are products, parts—tangible entities. Non-physical artifacts are those without mass, for example a shine, a brushed surface etc. Finally, there are meta-artifacts, those created to assist in the manufacture of other artifacts. For example an injection molding sprue of a model kit serves the purpose of grouping the individual parts, which are attached to it. Likewise RFID tags and OCR codes may serve the purpose of identifying artifacts. These artifacts exist to describe others—hence the term “meta.” Appropriate definitions may be found in table 19.
TABLE-US-00019 TABLE 19 Artifact Types expressed as CSP model PhysicalArtifact = ArtifactAction.fabricate -> PhysicalArtifact ------ Specification ----- Implementation assert ArtifactModel \{|ArtifactAction.craft, ArtifactAction.grouping, ArtifactAction.identify|} [T= PhysicalArtifact assert ArtifactModel \{|ArtifactAction.craft, ArtifactAction.grouping, ArtifactAction.identify|} [FD= PhysicalArtifact NonPysicalArtifact = ArtifactAction.craft -> NonPysicalArtifact ------ Specification ----- Implementation assert ArtifactModel \{|ArtifactAction.fabricate, ArtifactAction.grouping, ArtifactAction.identify|} [T= NonPysicalArtifact assert ArtifactModel \{|ArtifactAction.fabricate, ArtifactAction.grouping, ArtifactAction.identify|} [FD= NonPysicalArtifact MetaArtifact = ArtifactAction.grouping -> MetaArtifact [ ] ArtifactAction.identify -> MetaArtifact ------ Specification ----- Implementation assert ArtifactModel \{|ArtifactAction.fabricate, ArtifactAction.craft|} [T= MetaArtifact assert ArtifactModel \{|ArtifactAction.fabricate, ArtifactAction.craft|} [FD= MetaArtifact
[0090] Supply Layer Elaboration
[0091] The Supply Layer accommodates the core functions of the Supply Chain Interconnection Model and coordinates the other layers—relating for its network communication to the OSI model of the Internet. Please refer to
[0092] The “Robotic Capability Model” and the “Manufacturing Ontology System” are defined separately in the patent “ROBOTIC CAPABILITY MODEL FOR ARTIFICIAL INTELLIGENCE ASSISTED MANUFACTURING SUPPLY CHAIN PLANNING.” In brief, these comprise a system to enable artificial intelligence supported product design in an automated manufacturing setting employing the use of robots. For clarity, the SUPPLY layer definition is repeated here.
TABLE-US-00020 TABLE 20 Supply Layer Definition expressed as CSP model ------------------------ -- SUPPLY LAYER DEFINED ------------------------ SUPPLY = CCFM -- Consensus Contract-And- -- Feedback Model [|{|CertAct,CCFMAction|}|] ( GEO -- Geopatial Model [|{|GeoActionRef|}|] ( VRP -- Vehicle-Routing & -- Fleet-Optimization Model [|{|DIRmsg|}|] ( CERT -- Certificate -- & Security Model [|{|CertAct|}|] ( DIR -- Directory Services Model [|{|RCMMsg,RCMReq|}|] RCM -- Robotic Capability Model ) ) ) )
[0093] Consensus Contract and Feedback Model
[0094] The Consensus Contract and Feedback Model accommodates smart contract negotiation and feedback lodgment. In an early section, we asserted that the Supply Chain Interconnection Model derives its productivity multiplier from, among other things, the swift and continual inter-operation of actors as directed by the supply layer. The Consensus Contract and Feedback Model is directed at this requirement. Contracts for service may be negotiated directly on a peer-to-peer network and a record of contracts remains on a peer-to-peer ledger. An area of particular concern in a highly distributed manufacturing environment is how to manage quality control. Correction of inadequate processes must be immediate, impartial and trusted. Candidate technologies that have emerged recently which fit this role are blockchain consensus protocols and associated smart contracts, based on Federated Byzantine Agreement.
[0095] The model presented here does not advocate particular implementations but rather models consensus as a CSP abstraction. The model may be implemented based on Federated Byzantine Agreement, which has several commercial and open source implementations. Described here is the integration of peer-to-peer consensus into a manufacturing supply chain in order to agree contracts and provide quality feedback.
[0096] Table 21 defines the Consensus Contract and Feedback Model for CSP in the context of the Supply Chain Interconnection Model (SCIM).
TABLE-US-00021 TABLE 21 Consensus Contract and Feedback Model expressed as CSP model -------------------------------------------------------------------- -- Consensus Contract & Feedback Model -------------------------------------------------------------------- datatype CCFMState = UNCOMMITTED | VOTING | COMMITTED datatype CCFMActionType = sync | propose | accept | reject | respond datatype CCFMLedgerState = SYNCHRONIZED | UNSYNCHRONIZED channel CCFMAction : CCFMActionType CCFM = let Ledger(UNSYNCHRONIZED) = CCFMAction.sync -> CertAct.trust -> (CertAct.authorize -> Ledger(SYNCHRONIZED) [ ] CertAct.noauthorize -> Ledger(UNSYNCHRONIZED) ) Ledger(SYNCHRONIZED) = let Consensus(UNCOMMITTED) = CCFMAction.propose -> CertAct.trust -> (CertAct.authorize -> Consensus(VOTING) [ ] CertAct.noauthorize -> Consensus(UNCOMMITTED) ) Consensus(VOTING) = CCFMAction.accept -> CertAct.trust -> (CertAct.authorize -> Consensus(COMMITTED) [ ] CertAct.noauthorize -> Consensus(VOTING) ) [ ] CCFMAction.reject -> CertAct.trust -> (CertAct.authorize -> Consensus(COMMITTED) [ ] CertAct.noauthorize -> Consensus(VOTING) ) Consensus(COMMITTED) = CCFMAction.respond -> Consensus(UNCOMMITTED) within Consensus(UNCOMMITTED) within Ledger(UNSYNCHRONIZED) ------ Invariant ----------- assert CCFM :[deadlock free]
[0097] Geospatial Reference Model
[0098] The Geospatial Reference Model provides mapping functionality for transport capability.
TABLE-US-00022 TABLE 22 Geospatial Reference Model expressed as CSP model ------------------------------ -- Geospatial Reference Model ------------------------------ datatype GeoStatusType = MAPPED | UNMAPPED datatype GeoActionType = map datatype GeoActionRefType = reference_map channel GeoAction : GeoActionType channel GeoActionRef : GeoActionRefType GEO = GeoAction.map -> GEO [ ] GeoActionRef.reference_map -> GEO
[0099] Vehicle Routing and Fleet Optimization Model
[0100] The Vehicle Routing and Fleet Optimization Model provides on-demand route planning for mobile actors and fleets. In an early section, we asserted that the Supply Chain Interconnection Model derives its productivity multiplier from, among other things, the swift and continual inter-operation of actors as directed by the supply layer. The Vehicle Routing and Fleet Optimization Model is directed at this requirement. It aims to minimize costs and transport times for individual routes and whole fleets. It is envisaged that this is a distributed service that optimizes fleets for manufacturing clusters as well for the transport backbone.
[0101] Implementations of Vehicle Routing and Fleet Optimization include commercial and open source variants. As with the Actors model, we do not advocate a vendor specific implementation but rather model integration into the Supply Chain Interconnection Model (SCIM) in terms of the process calculus CSP.
TABLE-US-00023 TABLE 23 Vehicle Routing and Fleet Optimization Model expressed as CSP model ----------------------------------------------------- -- Vehicle Routing Planner & Fleet Optimization Model ----------------------------------------------------- datatype VRPReqType = order_source_destination datatype VRPMsgType = route_schedule channel VRPReq : VRPReqType channel VRPMsg : VRPMsgType VRP = let Geospatial(UNMAPPED) = GeoActionRef.reference_map -> Geospatial(MAPPED) Geospatial(MAPPED) = VRPReq.order_source_destination -> VRPMsg.route_schedule -> VRP [ ] ActorMsg.schedule -> VRP -- Actor registers its [ ] -- current schedule. ActorMsg.position -> VRP -- Actor registers its [ ] -- current position. DIRStatus.online -> VRP -- Directory advises actor [ ] -- is online. DIRStatus.offline -> VRP -- Directory advises actor -- is offline. within Geospatial(UNMAPPED) --------- Invariant ------- assert VRP :[deadlock free]
[0102] Certificate and Security Model
[0103] The Certificate and Security Model provides authentication and may provide non-repudiation and confidentiality. It is envisaged that this is a centralized service.
[0104] Security certificates are offered commercially. As with the Actors model, we do not advocate a vendor specific implementation but rather model integration into the Supply Chain Interconnection Model (SCIM) in terms of the process calculus CSP.
TABLE-US-00024 TABLE 24 Certificate and Security Model expressed as CSP model ------------------------------- -- Certificate & Security Model ------------------------------- datatype CertActType = trust | authorize | noauthorize channel CertAct : CertActType CERT = CertAct.trust -> (CertAct.authorize -> CERT |~| CertAct.noauthorize -> CERT )
[0105] Directory Service Model
[0106] The Directory Service provides registration capability for robotic actors and optionally for product descriptions. Please refer to table 25 for process logic.
TABLE-US-00025 TABLE 25 Directory Service expressed as CSP model --------------------- -- Directory Service --------------------- datatype DIRMsgType = ack | nack channel DIRMsg : DIRMsgType datatype DIRStatusType = online | offline channel DIRStatus : DIRStatusType DIR = -- actor registers ActorMsg.register -> CertAct.trust -> (CertAct.authorize -> (RCMReq.get_robot_definition -> ( RCMMsg.robot_definition -> DIRMsg.ack -> DIRStatus.offline -> DIR [ ] RCMMsg.rcm_fail -> DIRMsg.nack -> DIR ) ) [ ] CertAct.noauthorize -> DIRMsg.nack -> DIR ) [ ] -- actor deregisters ActorMsg.deregister -> CertAct.trust -> (CertAct.authorize -> DIRMsg.ack -> DIRStatus.offline -> DIR [ ] CertAct.noauthorize -> DIRMsg.nack -> DIR ) [ ] -- actor indictes availability ActorMsg.avail -> CertAct.trust -> (CertAct.authorize -> DIRMsg.ack -> DIRStatus.online -> DIR [ ] CertAct.noauthorize -> DIRMsg.nack -> DIR ) [ ] -- actor indicates unavailability ActorMsg.unavail -> CertAct.trust -> (CertAct.authorize -> DIRStatus.offline -> DIR [ ] CertAct.noauthorize -> DIRMsg.nack -> DIR ) [ ] -- actor registers its work/travel schedule ActorMsg.schedule -> CertAct.trust -> (CertAct.authorize -> DIRMsg.ack -> DIR [ ] CertAct.noauthorize -> DIRMsg.nack -> DIR ) [ ] -- actor advises its position ActorMsg.position -> CertAct.trust -> (CertAct.authorize -> DIRMsg.ack -> DIR [ ] CertAct.noauthorize -> DIRMsg.nack -> DIR ) ------ Invariant ---------- assert DIR :[deadlock free]
[0107] Robotic Capability Model
[0108] The Robotic Capability Model facilitates artificial intelligence supported product design in an automated manufacturing setting employing the use of robots. The use case supported by Robotic Capability Model is as described. Given a population of robots and a systematic product description, the described technology will be able to do the following: (a) Answer the question as to whether a product can be built—a feasibility analysis; (b) Detail the exact operations required to build a product end-to-end; (c) Formulate a manufacturing plan describing the robots required to build a product; and (d) Apply optimization constraints to feasibility analyses and manufacturing plans.
[0109] In an early section, we asserted that the Supply Chain Interconnection Model derives its productivity multiplier from, among other things, the swift and continual inter-operation of actors as directed by the supply layer. The Robotic Capability Model is directed at this requirement.
[0110] The Robotic Capability Model is defined separately in the patent “METHOD AND SYSTEM FOR AUTOMATED PRODUCT DESIGN AND OPTIMIZATION OF ROBOTIC MANUFACTURING SUPPLY-CHAINS.” The CSP model for the Robotic Capability Model is defined table 26.
TABLE-US-00026 TABLE 26 Robotic Capability Model expressed as CSP model ---------------------------- -- Robotic Capability Model ---------------------------- datatype RCMReqType = get_product_definition | get_production_plan | get_robot_definition | register_product_definition | register_robot_definition datatype RCMMsgType = product_definition | production_plan | robot_definition | rcm_fail -- Channels that RCM synchronizes on -- These are both client interfaces channel RCMReq : RCMReqType channel RCMMsg : RCMMsgType RCM = RCMReq.register_product_definition -> RCM [ ] RCMReq.register_robot_definition -> RCM [ ] RCMReq.get_product_definition -> RCMMsg.product_definition -> RCM [ ] RCMReq.get_production_plan -> RCMMsg.production_plan -> RCM [ ] RCMReq.get_robot_definition -> RCMMsg.robot_definition -> RCM ------ Invariant ---------- assert RCM : [deadlock free]
[0111] It is envisaged that the Robotic Capability Model is a distributed service that operates on manufacturing clusters with a root service coordinating query distribution and data replication. We define an indexed Robotic Capability Model using a parameterized variant of the Robotic Capability Model as shown in table 27. Other services hitherto represented as non-distributed may be parallelized and distributed in the same manner. CSP and FDR continue to provide of correctness.
TABLE-US-00027 TABLE 27 Indexed Robotic Capability Model expressed as CSP model ---------Indexed RCM-------------- MANUFACTURING_CLUSTER_NUMBERS = 10 RCM_SERVICE_NUMBER = MANUFACTURING_CLUSTER_NUMBERS + 1 ---- Node zero is root node RCM_DISTRIBUTED = ||| x : {0..RCM_SERVICE_NUMBER} @ RCM(x)
[0112] Inversion of Processing and Processing Overhead
[0113] The Robotic Capability Model, the Actor Model, and the Vehicle Routing and Fleet Optimization Model combine to invert the mode of operation of the traditional supply chain not only from a push-strategy model to a pull-strategy model but critically from a model centered on the notion of a supply chain where parts are moved between manufacturers providing value add processes to the notion of a grid of manufacturing clusters of low cost manufacturing facilities. As automation decreases the cost of manufacturing for individual processing steps in the sequence of steps required to manufacture products, productivity and manufacturing volumes are increased through lowering the overheads between manufacturing steps and restructuring the overall process to reflect this. The Robotic Capability Model and the Vehicle Routing and Fleet Optimization Model achieve an inversion of the dynamic between processing and processing overhead.
[0114] So called “big data” information systems leverage a similar inversion of the dynamic between processing and processing overhead today—but for such information systems the driving factor is an explosion of data volume, leading to a push for architectures designed to accommodate this volume. In manufacturing, by contrast, the driving factor is the lowering of costs through automation. Our architecture is designed to pull these lowered costs through to larger manufacturing volumes.
[0115] Please refer to