(c) Bruce Powel Douglass, Ph.D. 2019

Aug 8, 2018

Do request messages have the same signatures in the architecture phase?

1 comment

Edited: Aug 8, 2018

Suppose you have your system "S" that receives an event Ev1() and an operational contract called OP1(). During the architectural phase, you decide to fulfill the requirements with two blocks, B1 and B2. B1 receives Ev1(), but B2 is allocated the operational contract OP1(). Now between B1 and B2, a message is needed. I assume this is Ev1() again, it is just forwarded. However, I need them to be different, because it might be the case, that B1 performs some tasks on the parameters of Ev1() and then forwards the filtered data to B2. How would you model this? Do I need to invent a new message for this? I have seen in the examples in the paper from H. P. Hoffmann and the Harmony deskbook that the messages are just duplicated. I suppose Ev1() in the above example is duplicated but now has a different TYPE for its parameter. Afterall, the fact that I drew Ev1() from B1 to B2 has already created a new event on B2, so yes, they are different.

 

For the example in Hoffmanns' paper see figure 10, the operational contract is reqCalcCmdrLosCmd, which is shown several times between LRUs:

 

http://static1.1.sqspcdn.com/static/f/702523/9277834/1288929233000/200511-Hoffmann.pdf?token=F%2FmLJpHRBLG3JpdFzxeJcZZyB1I%3D

 

Aug 8, 2018

During the allocation of requirements and their model-based representations (events, event receptions, actions, and whatnot), many - if not most - cannot be directly allocated. They must be decomposed and the decomposed parts are then allocated. In general, an event EV1 in a use case might be realized the architecture as a collection of events and operations in many subsystems; That's the "interesting" part of allocation.

 

I give a detailed example in the Harmony aMBSE Deskbook (available in the Resource > Papers page on this website) in Chapter 9. In addition to decomposing the events into multiples, you typically also have to identify (derived) subsystem requirements and decomposed operations.

 

So in general, the EV1 event you references, which might come from an external actor, will show up as an input to some subsystem in the architecture. Rather than just perform operation OP1(), it might do OP1_step1() and then send message ev1_step2 off to subsystem 2 to perform OP1_step2, ev1_step3 to subsystem 3 to perform operations OP1_step3 and then OP1_step4, and so one.

 

For example: imagine an event evPedalDepress(position) which causes the cause to ApplyBraking() operation. Inside the system, the Pedal Assembly receives evPedalPress event, and it has internal operations to determinePosition(), determineForce(), determineSpeed() related to the pedal event. It then passes this information over the the BrakingController as applyBraking(position, speed, force) event and internally performs operation (determineBrakingForce(wheel1, wheel2, wheel3, wheel4); the BrakingController then sends an event ApplyBrakingForce(wheelID, force) to each of the WheelAssembly subsystems. ALL of this is derived from 1) the intial use case and 2) the system architecture.

 

Few systems are so simple that you can easily just allocate messages and serviced identified in the use case model directly and uniquely to subsystems.

 

I hope this helps.

- b

 

New Posts
  • Hi! I am reading in Chapter 8 of Agile Systems Engineering, while simultaneously reviewing the example model TWrecks1.rpy and have some questions. in ibCommCoord there are three flowProperties called cmdProximalJointAngle:JointRadian cmdMedialJointAngle:JointRadian cmdDistalJointAngle:JointRadian These are combined into the message CommandedJointAngleMsg:CANMsg with the following mapping: Data0:unsigned char = Low byte Proximal Angle Data1:unsigned char = High byte Proximal Angle Data2:unsigned char = Low byte Medial Angle Data3:unsigned char = High byte Medial Angle Data4:unsigned char = Low byte Distal Angle Data5:unsigned char = High byte Distal Angle In paint it would look something like this: Now to my questions: Why are there no explicit relation between the logical flowProperties and the physical data? Wouldn't that kind of traceability be beneficial to know exactly how the logical data schema is refined into the physical? It feels unsatisfying on relying on the semantics of the text string to indicate traceability. If I where to add such a relation how would I do it in the best way? To I have tried to use «allocate» and «dependency» , but that can only be done between the interface specification and the flow property and not to the exact value (Data0, Data1, ...). See below: Thanks in advance! Best regards Markus
  • Dear Bruce, I have some problems with abstractions/ kinds of subsystems, especially with logical and physical. The reason is, that logical subsystems often map to multiple physical subsystems and a physical subsystem can contain multiple logical subsystems. In one of your SE book there is an example for physical subsystems. [...] For example, an automotive braking subsystem will contain mechanical (brake pedal, braking pads), hydraulic (pistons, o-rings, pump, fluid reservoir), electronic (ECU,2 pedal position, wiring), and software (ABS) components [...] (1) With this description, I would model an _subsystem and components view_ that has separate components ECU and software, even if the software do run on the ECU of course. I would show this relation in an separate view? What is necessary in Handout and is it an SE or SW task? It is always difficult for me to separate Systems Engineering from native downstream disciplines. (2) When I show logical subsystem, then it may be possible that a subsystem contains hydraulic, electric parts and SW. In a _deployment view_ I have to identify the engineering disciplines. Right? (3) Which possibilities can I use to show the relation of logical parts of deployment view and physical components? Thank you very much! Best regards Matthias
  • What are your hot questions and systems engineering and MBSE?