version 1 (see Old Versions)

  • Is it necessary to talk about Measurements?
    • mw: Don't think so. The measurements are taken against the plant. Btw, I should probably clarify the term "plant" in the context of feedback systems. This is generic term to refer to the system being controlled (eg a furnace), and is not used in the specific sense of a plant that manufactures some good. Anyhow, this only affects the Plant actor as far as I can see.
  • Should measurements be part of Feedback?
    • mw: I tried it, and it seems to make most sense to place measurement with the plant. When a measurement is made (eg they could be made periodically, whatever), the feedback controller should be notified.
  • There are many non-functional requirments which could be shown on the diagram. I decided to show response time and accuracy as they seem to be the most important ones.
    • mw: The NFRs I had identified from reading the requirements were:
      • flexibility (ie need to change control strategies easily and with minimal impact on other parts of the system),
      • loose coupling (ie stages should not be hard-wired),
      • timeliness (probably close to your response time, ie how quickly the feedback component is informed about a new measurement; consider that if we used polling, we might either not respond quickly enough, or incur too much processing overhead for needless requests as the measurement has not changed yet; for this one, I think the discussion of updating the inventory from the BPM paper could be relevant).
      • however, accuracy could probably be included as well: it is to a large part affected by two things, (1) the quality of the measurements (its granularity), and (2) the sophistication of the control strategies (eg a strategy that uses multiple earlier measurements t(n), t(n-1), ... would typically lead to a smoother system response (think of what would happen if you made a full-stop every time whenever the car ahead of you gets too close)
  • There are (repetitive) soft goals inside an actor. The reasons for this is that jUCMNav does not allow to link dependencies to actors, therefore requiring an intentional element inside the actor.
  • The actor and the soft goal have almost the same name. The reasons for this is that actors and soft goals cannot have the same name, therefore requiring the prefix sg.

version 2 (see Old Versions)

  • added new version which takes all comments for version 1 into account
  • removed all actors inside the Feedback Control System actor and replaced them with goals
  • the project is now structured into three levels (the first and second are shown below, the third is shown on Goal Feedback, Goal Error Calculation, and Goal Feedforward)
  • the first level shows the dependencies between actors
  • the second level shows the high level breakdown of the Feedback Control System actor as well as all dependencies from level 1 which are relevant at the second level
  • the third level shows the solution space (i.e. different combinations of patterns and the impact of patterns), dependencies from level 1 which are relevant at the third level are also shown
  • tested: when selecting the pattern combination by entering 100 in the evaluation level field of each used pattern, the evaluation is propagated throughout the model

version 3 (see Old Versions)

  • typos

version 6 (see below)

GRL Diagram

Feedback Control System Dependencies

Feedback Control System

-- Gunter Mussbacher - 22 Mar 2006

Topic revision: r6 - 24 Mar 2006 - 14:35:04 - Gunter Mussbacher
Work.FeedbackControlSystem moved from Work.FeedbackControlSystemDependencies on 23 Mar 2006 - 22:54 by Gunter Mussbacher - put it back
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback