Which class should hold this data...

[GregFreeman]

I have a pretty simple process that I'm sticking in parallel to some other things. It is a "manager" that holds in it's private data an array of "zone" classes. These zones are essentially simulated devices. When an incoming message comes in (CAN bus), that message contains information on which zones the data applies to. Some messages are broadcast so the same data applies to all zones, some are zone specific, with the zones to which the data applies to being specified within the incoming message The message data is then applied to those specified zones (i.e. their private data is updated accordingly), and then an outgoing message is created to be sent out.

I am not exactly sure how to handle the outgoing messages when I have zone specific data. For instance, a message comes in and says update zones 1,3,and 4. So I update those zones, but then I need to respond back out with multiple messages, saying zone 1 updated, zone 3 updated, zone 4 updated.

So I have a couple thoughts. The way I have it now, in the "managers" private data I have a "zones to execute" array and I also have a single outgoing message. When an incoming message is received, I inject the proper outgoing message that will be sent. When the outgoing message is being sent, loop through the zones to execute array, find those appropriate zones, grab the necessary data, update the "outgoing messages" data and send it.

Or, I could have my "outgoing message" class hold the "zones to execute" but follow a similar style to the above. Instead, I'd use an accessor to get the zones to execute out of the message class.

Finally, I could still have the "zones to execute" in the manager class. But, each zone could hold a CAN bus reference and they could handle sending out the CAN messages from within themselves. I'm not sure I like the idea of the single CAN reference being held by multiple different zones, though, when it is the manager handling the opening and closing of the reference.

Does anyone have a better suggestion? If you need clarification let me know.

Edited December 4, 2012 by for(imstuck)

[MarkCG]

Finally, I could still have the "zones to execute" in the manager class. But, each zone could hold a CAN bus reference and they could handle sending out the CAN messages from within themselves. I'm not sure I like the idea of the single CAN reference being held by multiple different zones, though, when it is the manager handling the opening and closing of the reference.

Why not make the CAN reference an input to whichever zone class methods will use it?

[GregFreeman]

Why not make the CAN reference an input to whichever zone class methods will use it?

It's not so much that, but that fact that I don't know if the zone itself should handle the writing to the CAN bus, or the manager should. I understand how to make it work if I want the zone to do the writing, but should the zone own the WriteToCan method in the first place is what I'm struggling with.

Edited December 5, 2012 by for(imstuck)

[JamesMc86]

What is the message? Is it simply an Ack or something more.

I think this is a question of responsibility. It sounds like this manager is a zone manager. It is receiving messages and dispatching to the zones so it strikes me that likely it should also be responsible for returning messages about the zones. Now if it is a simple ack that the zone has been modified, as the zone manager is responsible for performing the modification it should also be responsible for generating and sending the ack message. If this is something more specific then it should probably be generated from the zone somehow but the zone manager is still responsible for communication with the outside world and should be in charge of the communication.

In the context that you have given I think this would be my preferred route but I suspect any that you describe could be successful.

[GregFreeman]

What is the message? Is it simply an Ack or something more.

I think this is a question of responsibility. It sounds like this manager is a zone manager. It is receiving messages and dispatching to the zones so it strikes me that likely it should also be responsible for returning messages about the zones. Now if it is a simple ack that the zone has been modified, as the zone manager is responsible for performing the modification it should also be responsible for generating and sending the ack message. If this is something more specific then it should probably be generated from the zone somehow but the zone manager is still responsible for communication with the outside world and should be in charge of the communication.

In the context that you have given I think this would be my preferred route but I suspect any that you describe could be successful.

Thanks James, I agree. I will go with my "gut feeling" on this one and can modify if needed. That said, in doing the architecture design (we're sticking this into an existing code base which can often be a mess) we realized the current "manager" approach may not work as expected when some external devices are simulated, some are real etc (not just zones but other devices on the system). So, this problem may be a non-issue after the rearchitecting is finished. We shall see...

[MikaelH]

Here is a quick example using active objects.

Zones.zip

[drjdpowell]

Didn’t really follow the description of the problem (you’re sending message classes over a CAN bus?) but the fact that you have a reference (the CAN bus) that is needed by multiple processes (the zones) suggested there should be one dedicated process to encapsulate that reference. It shouldn’t be the Zone Manager because that has a well-defined job (managing zones) that is independent of CAN bus. So you need a “CAN bus actor/active process/whatever” that is the gatekeeper of the CAN bus and forwards all the messages.

[GregFreeman]

Didn’t really follow the description of the problem (you’re sending message classes over a CAN bus?) but the fact that you have a reference...

Sorry, to clarify I have CAN bus messages classes, which have a "generate can bus message" method that formats that class's data and returns it in a format the CAN driver accepts.

So you need a “CAN bus actor/active process/whatever” that is the gatekeeper of the CAN bus and forwards all the messages.

This above sentence is the route we have gone when refactoring. Breaking these things out into more dedicated processes.

I think most of the problems arose from the following:

There is firmware on the hardware that runs, which we are trying to simulate. When the hardware is present we do nothing, the hardware does everything itself. So, we are not interfacing with the hardware at all in our application. We are purely writing a simulator should the hardware not be there.

If the hardware is present, there are multiple zones. Each of these zones has its own buffer with the same CAN bus split and wired into it. Because of this, a single message can be sent out on the CAN bus, but each zone can still read that same message.

Now, when I simulate this idea of multiple zones in software, I don't have this ability. I can't structure it the same as the hardware (multiple zones each reading the same CAN message) because can't have multiple readers of the CAN bus in my software. So, I have to take the idea James suggested and read in a single place, pass it off to the zone managers, they respond, then write in a single place.

Does this make a little more sense? I think the confusion came from trying to have the same architecture as the firmware (multiple zones all reading the same message off the CAN bus) but this is not possible in a simulated environment on the PC.

Edited December 6, 2012 by for(imstuck)

[ShaunR]

I think the confusion came from trying to have the same architecture as the firmware (multiple zones all reading the same message off the CAN bus) but this is not possible in a simulated environment on the PC.

Actually it is quite possible. Use Events and all zones register and filter for messages. This is directly analogous to what the CAN bus is doing.

[GregFreeman]

Shaun, yup, this is what I plan on doing. I just meant the ctual CAN read I can't do in every zone