hello
I'm a researcher at a university and i'm looking into a system to use as a SOA manufacturing service bus. My instructions are to look for a MSB to which you can present the services each of your systems provides and requires, and then they get matched by the MSB.
I've looked at the chocolate factory example (https://www.rti.com/developers/case-code/process-automation) and that seems it might be along the lines of what i'm looking for, but i can't seem to figure out how i'd actually use it in an industrial application. Our MES system and equivalents to recipe generator and station controllers are pre-existing systems. how would i go about coupling them together with DDS? Do i have to write an application to sit between each of the pre-existing systems and the data bus? what would be the best way for those applications to commuicate with the pre-existing systems?
Any help would be appreciated
Hi Edward,
tl;dr: Yes, no and sometimes (in response to, "Do I have to wrie an application to sit between each of the [systems]").
Certainly, applications (ie, "bridges") need sometimes be built. Sometimes you can use Routing Service (actually, *generally* you can use Routing Service, and I would advise doing so always, when you have a choice between a bridge and a plug-in -- RS gives you options beyond just acting as a bridge, for example the ability to temporarily disable a route). Sometimes it makes more sense to use rtiddsgen to generate a library that you build into your existing applications rather than bridging or routing. It is heavily dependant on ... "It depends".
When grafting DDS into an existing system, you have to do a systems analysis up front, to determine where a "node" (maybe a sensor, a gateway, an application, a system or a system-of-systems!) connects to some other node.
For me, I tend to need a visualization of the system graph, can't keep it in my head.
From that graphic, I build an XML representation of the graph that I compile into IDL (my own compiler), do code generation steps to provide default libraries etc. This step builds the middleware ... runtime? environment? dunno. Let's use "fabric". It builds a complete infrastructure fabric that exists _between_ the notional nodes -- it does not yet actually do anything with or for the nodes, it simply exists as libraries, routing service plug-ins and/or stub bridges, and an understanding of topic names, topic types, and uses the default QoS. The generated stub bridges and RS plug-ins have all the DDS parts and application param/configuration handling in place, just need to hand-build the legacy protocol <-> DDS type conversions (done correctly, this protocol mapping can be used in either the bridge or the RS plug-in. Occasionally the client asks for something that can't be done easily using RS, or when done in RS there isn't sufficient control over the non-functional behavior, or RS adds an unnecessary latency into a data flow.
So now I have a legacy framework like ([a0, a1, a2] -> b <-> [c, d]) (sensor group a sends to gateway b, which has two-way comms with applications c and d). And I have the arrows (topics and types) that make up the fabric, and the arrow heads (libaries, RS plug-ins and bridge applications) that are the interfaces between the fabric and the not-fabric.
Next step is to pick two things ("sensor a0 and bridge b") and modify their connection strategy, to talk to the middleware (the middleware!) rather than to the other thing. A0 will talk to the middleware, and bridge B will talk to the middleware. Sometimes you have code for a0 that you can change, or maybe a0 represents a sensor talking to a raspberry pi or some other small system controller, in which case you need to alter the code in the controller, but the goal is to get the sensors' data into the middleware, and to pick the sensor data out of the middleware.
Then iterate through the spreadsheet, moving (my preference, but heavily influenced in case-by-case) edge devices onto the bus, and then the bridges to the applications, and then the applications to each other. Eventually systems-of-systems are talking to each other over the databus. If I have a team working with me, I get them connecting the applications while I start with the sensors (as those will be easier for me, and mostly generic, and it doesn't expose the clients IP [their applications] to me, the consultant. Eventually we meet in the middle.
Then we start tuning QoS, looking for edge conditions, figuring out latency problems, determining where a hand-coded application's speed tradeoff vs RS plug-in is necessary...
Keep in mind that it is possible to run (in some cases, and in debugging) the legacy client->server connections in parallel with the DDS traffic. Eventually the legacy part is deprecated, then turned off, then removed, the system tested and then shipped to the field.
The above describes a process for going from an entire non-DDS system to an entire DDS system. BUT: All situations are their own raft of possibilities. Exceptions abound, and these may be either functional or non-functional (typical "non-functional exception" is insufficient resources to change everything this year, need another budget cycle, we can do the rest later... etc). Or you have plant that it simply makes better commercial sense to leave be (20yo sensors with a 25yr lifespan in a six year project to migrate a distillery from its legacy to DDS? don't bother, just make the replacement sensor be DDS from the outset).
etc. etc.
I actually enjoy migrated legacy systems to DDS rather than greenfield DDS development.
Keep in mind that all of the above discusses migration, it does not talk about data security, whether the traffic needs to be secure at the transport layer or whether the instances (an instance of data traffic on a topic) needs to be out-of-band encrypted/MACd, or whether to use DDS Security plug-ins to secure the fabric. That is an additional discussion because it has to take into account things like, can the sensor do an ECDH key exchange with its peers? Can it even do ECC or does it only support AES? Or at all?
If you are getting academic papers out of this work, happy to provide guidance on all this (including the Security part, which is what I do now)