Architecture for message based communicaiton

Well thanks your feedback, it's hard to tell more about the topic as it involves plenty of details...
But let's give a try:

Basically, we have different product:
- A Controller to perform measurement channel inputs (e.g. Current, Voltage, Frequency, Digital, Relay, etc.) and generate some signals on its outputs (AWG, Voltage, Frequency, Digital, etc.) and some typical automotive buses: CAN, LIN and K-LINE.
- A Unit, able to deal with the power supply and to embed several controllers.
- An Extension to perform some temperature measurements and bring, it's connected to the Unit.

The fact is the embedded team who (is charge of designing all the dirty stuff over the hardware) gave me the commands and acknowledgments are not really clear, neither user-friendly, and for some legacy reasons they're not gonna change that...
Mainly cause prior to that situation we used to have a software dealing directly with the commands and it was a huge huge huge mess. Since I decided to gather all the communication stuff in assembly dedicated to that. It allows btw to make instrument drivers (for NI LabVIEW) by wrapping the objects and methods of the assembly. I'm pretty proud of that cause it allows our systems to be used in many many different Software platforms (e.g. Matlab) and in our own software platforms as well. I also manage myself to make our assembly Mono compliant.

The protocol as it has been defined it not that extensible (not necessarily there is a need to make it extensible but I feel sometimes that it could be better).
Unit Command: {@}{UnitId}{XX}{_}{UnitMessageKeyword}{=Parameters}(if any){;}
Unit Acknowledgment: {#}{UnitId}{XX}{_}{UnitMessageKeyword}{=Answer}(if any){;}

Controller Command: {@}{ParentUnitId}{ControllerId}{_}{ControllerMessageKeyword}{=Parameters}(if any){;}
Controller Acknowledgment: {#}{ParentUnitId}{ControllerId}{_}{ControllerMessageKeyword}{=Answers}(if any){;}

Extension Command: {@}{ExtensionId}{XX}{_}{ExtensionMessageKeyword}{=Parameters}(if any){;}
Extension Acknowledgment: {@}{ExtensionId}{XX}{_}{ExtensionMessageKeyword}{=Parameters}(if any){;}

Controller Instead to provide a dummy interface with the command to the end users, I decided to gather messages and acknowledgment into things what really the user needs through properties, it's more natural as it really represents the Unit:
- Property (Category) Power Supply => Enabled { get; set; } / CurrentMax { set; get; } / Current { get; } / Voltage { get; set; }
- Property (category) Information => SubCategory Identifiers { get; } / SubCategory OperatingTimes { get; } / etc.
- Method On() // Turn On...
- Method Off() // Turn Off...
- Method Lock() // Remote Control Only
- Method Unlock() // Allow Manual Mode
- ReadOnlyKeyedCollection<controller,>
- Etc.

Lock() / Unlock() methods could be gathered as a Boolean Property Locked { get; set; }
The same for On() / Off() methods into Powered / On { get; set; } or whatsoever.

The fact is that we are making new products, some of them are based on the previous one: like a Controller which is out of the unit for the customers who do not need a big power supply.

I was just suggesting factories for better re-usability matters, the fact is my solution now is a bit boring to implement and I'd like to make things easier. The core of the troubles are that there is an underlying implementation of the messages. For some reasons a Message Keyword does not necessarily match a Command Implementation in the assembly, sometimes the possibilities for one keywords are simply too much (and can lead to have a lot of Nullable as properties of the message), therefore when it's possible a keyword can be used in different command implementations when the concerns are properly separated.

Message
^- Acknowledgment (Token Reception: Start / Stop)
^- AcknowledgmentUnit
^- AcknowledgmentController
^- AcknowledgmentExtension

^- Command (Token Transmission: Start / Stop)
^- CommandUnit
^- CommandController
^- CommandExtensi