2

We are building a multi-device (different vendors, different types) manufacture machinery where these device work together orchestrated by our software and operated by a human being to create various products.

We are currently working on establishing an architecture for handling many different devices with an outlook on:

  1. Device auto-discovery and wizard like configuration.
  2. Easily adding new vendor devices support.

The software runs on Windows machines and besides hardware specific logic has quite a lot of domain logic on product creation.

Initial thoughts are to focus on reducing coupling between domain and hardware logic, so that adding new hardware would require minimum amount of work and on a very isolated part of the code base, thus hopefully making it easy.

For this purpose we are looking into making use of ports and adapters architecture where the domain logic describes what features it needs as ports and the hardware module implements them via specific drivers based on currently available hardware as adapters.

Since we have multiple vendors that offer devices which share functionality, we also want to add an abstraction layer on top of it to describe abstract devices without coupling ourselves into specific vendor when implementing features.

For the details of handling multiple devices, managing connectivity, etc. we are looking into architecture very similar to the Linux kernel, where we have multiple bus types (USB, serial, Ethernet, etc.) where in turn each has its own list of available drivers (in this case a driver is a piece of software enabling some features for the domain). Then there is a device, which when connected to a specific bus gets probed by available drivers until a match is found and attached to the device, which is then initialized and prepared for usage.

Here is a diagram summarizing the current architecture: architecture diagram

At this point in time a combination of ports and adapters architecture and a Linux-like handling of specific vendor hardware seems to make sense. But this was designed mostly following generic architecture practices.

Therefore the question is two-fold:

  • Are there any flaws identifiable at this point in time with the current design?
  • Are there alternative established architectures specific for multi-device machinery?

Any other suggestions/comments are welcomed.

1

Are there alternative established architectures specific for multi-device machinery?

Established architectures only emerge when similar (architectural-level) problems have to be solved in a multitude of system designs. I think your problem of supporting multiple, interchangeable, devices from different vendors is common enough to form an established architecture around.

You did well to look at how operating systems solve that problem.

Are there any flaws identifiable at this point in time with the current design?

I would not directly call it a flaw and you may disagree with me as you are deeper into the details.

Based on the description you gave, I would have marked the Hardware Abstraction Layer as being the Ports for the Port-and-Adapters pattern within your architecture. But then, you didn't indicate in the diagram what your ports are, so I just assumed it were the classes you drew on the edge of your user-space.

1
  • A perceptive notice on ports and Hardware Abstraction Layer. We haven't yet defined/designed the domain space which will be one of the clients for this hardware component and it shows that the boundary line between these is a bit blurry. Thank you. Jan 7 at 7:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.