8.3 RFD analysis of task T11
This section aims to summarise each of the episodes presenting partial narratives of the design story in terms of the experimental objectives and the vocabulary of the RFD model from chapter 6. Thus, each episode is associated with an appropriate design context and design frame. Some are clearly embedded in a single frame (e.g. 8.2c or 8.2d), whereas others serve as a transition from one frame to another one.
Typically, the second scenario appeared in the cases when the original frame was found insufficient or incomplete, and a need arose to articulate new conceptual terms (e.g. 8.2b or 8.2e).
The narrative flow of the design story is interspersed regularly by major ‘achievements’. These achievements express the explicit commitments of the designer to a particular specification and all contain a solution associated with them. The designer recorded such ‘milestones’ when he decided to commit himself to certain conclusions that typically arose from the justifying threads. Thus, there is a visible relation between the two forms of talking about the same design problem. Explicit achievements represent separate design contexts or frames without any causal relations among them. The narratives serves as a lead capturing certain decisions or chains of decisions that shift the design from one frame to the next one. In some cases, the narratives are longer (e.g. between 8.2/DC-II and 8.2/DC-III), which may suggest that the designer spent more time developing the next step or decided to merge several discovered issues together. Other sequences of narratives are shorter, which may suggest an immediate verification of the proposed resolution of the discovered conflict.
Design episode 8.2a
Design episode 8.2a serves as an initialisation of the problem solving space. It takes as an input the design brief – we may label this using our symbol $3$3$3. Broadly, the reasoning steps performed by the$3 designer were categorised as a retrieval of familiar frames (past design cases) that were similar to the current problem. The retrieval was followed by the articulation anf selection of the relevant concepts that helped specify the current problem $3$3$3. In other words, we believe the purpose of design episode$3 8.2a can be expressed as our relation ‘specifies(S, $3$3$3$3)’ (see also section 6.2).
Reasoning step(s) observed in episode 8.2a:
Retrieval of a familiar frame (action #2)
Articulation of S, 6666 similar to a familiar frame (action #3a) Design episode 8.2b
The second chain of reasoning (design episode 8.2b) can be seen as a development of the initial frame. Thus, it features a commitment to certain explicit specification S (goals, objectives of the session). However, unlike 8.2a, this episode already introduces the conceptual primitives that could be used to implement a solution satisfying the given specification. In the terms of our theory, this chain explicitly articulates the conceptual elements 777, and the appropriate knowledge space 77 777* – a problem
solving theory for this design frame. We also noted that some of the concepts were only introduced, others were also elaborated into deeper details.
Reasoning step(s) observed in episode 8.2b:
Frame articulation – specifies (S, $3$3$3$3) (action #1a) Articulation of T, 777 similar to a familiar frame (action #3b)7 Further development of articulated frame 〈7777, 6666〉 (action #6a, 6b)
Design episode 8.2c
Design episode 8.2c further extends the approach started in 8.2b. However, unlike in the previous narrative, first conceptual sketches appear at this stage – prototypic solution or in language of our theory, one potentially applicable problem solving model T⊆ 7777* is explicitly articulated. This articulation happened in terms of a familiar design frame (spring as a body of the shock absorber). The specific commitment to a particular problem solving theory enabled further refinement of the problem specification (S) and conceptual foundation (7777) – e.g. specific physical quantities were specified. First time in the design process, we observed the search for an admissible problem solving model T⊆⊆⊆⊆ 7777* trying to satisfy the explicit problem specification developed so far (see predicate ‘satisfies(T, S)’ in chapter 6).
Reasoning step(s) observed in episode 8.2c:
Retrieval of a familiar frame (action #2)
Articulation of T, 777 similar to a familiar frame (action #3b)7 Further development of articulated 7777 (action #6b) Re-using a familiar component (action #5) Is re-usable component admissible? (action #4) Design episode 8.2d
The informal proposal of a solution candidate in episode 8.2c was followed by the assessment of consistency. At this stage, the designer uncovered the first potential conflict (see 8.2d). He addressed this conflict by refining the specification of the problem (certain property must be variable) and bringing in a new frame (new familiar case). New frame introduced new conceptual terms, especially at the level of ‘structural primitives’ for the construction of solutions (set 7777), e.g. a pneumatic piston.
Reasoning step(s) observed in episode 8.2d:
Further development of articulated 7777 (action #6b) Retrieval of a familiar frame (action #2)
Articulation of S, T, 7777 similar to a familiar frame (action #3a and 3b) Is re-usable component admissible? (action #4)
EXPLICIT ACHIEVEMENT 8.2/DC-II
Having informally assembled the pieces, the designer decided to make the first ‘official release’ of a solution to the problem as he framed it. He confirmed his commitment to the informally considered requirements (see R-1 to R-6 in 8.2/DC-II) and sketched a solution addressing them. In other words, he constructed a problem solving model T, which satisfied the earlier-mentioned explicit requirements.
Thus, he arrived at the first candidate solution that could be assessed for acceptability.
Reasoning step(s) observed in context 8.2/DC-II:
Frame articulation specifies/satisfies (action #1a and 1b) Further development of articulated 〈7777, 6666〉 (action #6a and 6b) Applying admissible components (action #5)
Design episode 8.2e
As the two subsequent episodes (8.2e and 8.2f) prove, the candidate solution was not entirely acceptable, and the designer modified his current interpretation of the problem. One part of the frame that showed potential for a modification was identified as inflexibility in the control algorithm. In order to fix this issue, the designer articulated a new requirement covering this incompleteness and extending his existing interpretation of the term ‘active suspension’ that emerged in one of the initial frames.
Reasoning step(s) observed in episode 8.2e:
Solution acceptability assessment (action #7) Frame amendment (action #8)
Refinement of problem specification (action #6a) Applying admissible components (action #5) Design episode 8.2f
In a similar manner, another issue was brought forward in design episode 8.2f, which eventually led to a modification of the initial assumption R-2. Drawing on his past knowledge, the designer refined the original statement R-2 to reflect better the changed ‘definition’ of the term ‘active suspension’ from the previous episode. Thus, episodes 8.2e and 8.2f focused particularly on the refinement and extension of the original problem specification (S Æ S’⊆ 6666*).
Reasoning step(s) observed in episode 8.2f:
Solution acceptability assessment (action #7) Frame amendment (action #8)
Retrieval of a familiar frame (action #2)
Articulation of S similar to the familiar frame (action #3a) Design episode 8.2g
Before validating these modifications of the original frame, the designer also tackled the issue of having too abstract conceptual primitives to work with (i.e. set 7777 and consequently 7777*). Therefore, in episode 8.2g he refined and elaborated into details the specific implementation of the components known in the previous explicit context (DC-II), such as measurement of piston displacement or the chassis clearance. Conceptually, he focused more on refining the ‘structural primitives’ rather than extensions or modifications of the problem specification.
Reasoning step(s) observed in episode 8.2g:
Solution acceptability assessment (action #7) Admissibility/completeness check (action #4) Retrieval of a familiar frame (action #2)
Articulation & refinement of T, 7 similar to familiar frame (actions #3b, 1b)
EXPLICIT ACHIEVEMENT 8.2/DC-III
Having found potential remedies to the identified inadequacies, the designer made the second explicit commitment to propose a candidate solution – i.e. to satisfy the amended specification. In the transcript, this step is recorded as an explicit achievement 8.2/DC-III and respective solution (sketch) is labelled as S-2. As it happened with solution S-1, the acceptability of the proposed candidate had to be established.
Reasoning step(s) observed in context 8.2/DC-III:
Frame articulation specifies/satisfies (action #1a and 1b) Further development of articulated 〈7777, 6666〉 (action #6a and 6b) Applying admissible components (action #5)
Design episode 8.2h
Although more complete than S-1, the latest proposal still contained unacceptable features. Thus, as the design episode 8.2h shows, the candidate failed the acceptability test. The designer refined the current specification, and decided that the potential reason for failure could be the lack of co-ordination between the two sub-controllers of the overall solution. Thus, a new requirement was added and a corresponding set of structural primitives was identified. In other words, this frame modification focused more on the clarification of existing specification (S) and the extension of the current
‘conceptual base’ (7777 Æ 7777’).
Reasoning step(s) observed in episode 8.2h:
Solution acceptability assessment (action #7) Frame amendment (action #8)
Refinement of problem specification (action #6a) Design episode 8.2k
The concepts that emerged in the design episode 8.2h were further elaborated in 8.2k pushing the vague notions from 8.2h into more specific terms, such as ‘interface’ and ‘translation’. On the level of problem specification (S, 6666), the purpose of the interface was expressed in terms of typical scenarios that needed to be addressed. In the space of conceptual primitives (777), a fuzzy controller emerged in7 addition to the original ‘quantitative’ ones in order to translate the driver’s ‘qualitative’ requests.
Reasoning step(s) observed in episode 8.2k:
Retrieval of a familiar frame (action #2)
Articulation of T, 7 similar to familiar frame (actions #3b) Is re-usable component admissible (action #4)
Applying admissible components (action #5) EXPLICIT ACHIEVEMENT 8.2/DC-IV
The proposed modification of the frame used in context DC-III was verified by an explicit commitment to the new requirement and construction of another solution (S-3). This sequence is recorded as an explicit achievement 8.2/DC-IV. The new problem solving model (T⊆ 7777*) was articulated so that it satisfied the modified problem specification (S) and was assessed for acceptability.
Reasoning step(s) observed in context 8.2/DC-IV:
Frame articulation specifies/satisfies (action #1a and 1b) Further development of articulated 〈7777, 6666〉 (action #6a and 6b) Applying admissible components (action #5)
EXPLICIT ACHIEVEMENT 8.2/DC-V
The acceptability test did not pass ‘unconditionally’, because the designer made a small amendment to the frame from context DC-IV before declaring a design solution. However, as record 8.2/DC-V shows, this was not so much the failure of the acceptability test as the completeness and clarity test.
Nonetheless, it triggered minor refinements of the structural primitives in the problem-solving model T, and led to a refined conceptual frame in the new explicit context DC-V.
Reasoning step(s) observed in context 8.2/DC-V:
Solution acceptability/admissibility checks (actions #4 and #7) Further development of articulated 〈7777, 6666〉 (action #6b) Applying admissible components (action #5)
The following breakdown in Table 8–2, gives a more concise account of our interpretation of the recorded and annotated design sequence. For clarity, the interpretation is conducted using the
vocabulary from chapter 6. The legend associates the referential numbers of reasoning steps with the verbal descriptions. The columns correspond to the individual design episodes of the narrative as described earlier in section 8.2. The values in the individual cells reflect the ‘order’ in which the different actions were observed (if possible).
Table 8–2. Conceptual summary of task T11 (see design episodes 8.2a to 8.2k)
‘action’ a b c d DC-2 e f g DC-3 h k DC-4 DC-5
1a 1. 1. 1. 1.
1b 1. 4. 1. 1.
2 1. 1. 2. 3. 2. 1.
3a 2. 3. 4.
3b 1. 2. 3. 3. 2.
4 4. 4. 1. 3. 1.
5 3. 3. 4. 3. 3. 3. 3.
6a 2. 2. 3. 2. 3. 2.
6b 2. 2. 1. 2. 2. 2. 2.
7 1. 1. 1. 1. 1.
8 2. 2. 2.
Legend to Table 8–2:
Reference Verbal description of referenced action 1a Articulate frame Æ specifies(S, $3$3$3)$3 1b Articulate frame (conceptual part 7777) 2 Retrieve similar frame ( φ = 〈τ, θ〉 ) 3a Articulate S, 666 similar to 6 θ 3b Articulate T, 7777 similar to τ 4 Is re-used τ and/or θ admissible?
5 Exists such T that satisfies given S 6a Develop S, 6666 into details (incl. alternatives) 6b Develop T, 7777 into details (incl. alternatives) 7 Is candidate solution T acceptable?
8 Re-interpret current frame (i.e. S Æ S’ )
8.4 Annotated task T21 – paper-smoothing plant
The initial problem specification or design brief given to the designer for this particular problem reads as follows. Paper-milling plant consists of several different chains of machinery that produce different types of paper. We are interested in one particular plant that takes semi-finished paper on a roll as an input, smoothes it, and rewinds it on another roll on output.
Your task is to design a part of a paper mill that would perform the above-defined operation, and ensure that the paper is evenly thick, smooth, and wound tightly on the output. The raw paper at the input may have ripples, variable thickness, rough surface, or any combination of these features. In addition to the design of a plant, suggest also a robust strategy for the regulation of such a plant, particularly with regard to paper thickness and strength changing case to case.
Design episode 8.4a
Initialisation of the first frame in context DC-I
Design context: DC-I Justifying threads: J-690 to J695
As in the other experimental cases, the designer used the design brief as shown above, and conducted an initial task analysis that aimed to clarify the objectives and specify the problem in more formal language. The introduction to the problem was made in record J-692, in which the designer sketched
how an input and output to/from the designed system might look like. Based on the initial drawing, he started articulating the parameters describing the problem in the language of design, and expressed their desired functionality of the designed system {J-693 to J-695}.
While the reference to the past experience is observable in threads J-694 and J-695, it is more subtle than in some other cases. The designer used a familiar vocabulary of concepts such as ‘reducing paper thickness’, ‘polishing paper surface’ to articulate the initial frame for the interpretation of the problem.
The past experience is observed in J-695 when he attended to the issue of how much the paper thickness would be modified by the system. This initial frame led to the formal expression of the task objectives explicitly articulated later in context DC-II.
Design episode 8.4b
Development of the initial frame and the emergence of explicit objectives
Design context: DC-I Justifying threads: J-696 to J704
In addition to the clarification of the concepts from the design brief (see 8.4a), the designer brought forward several additional parameters and requirements. As can be seen from the records, these originated in his generic knowledge of the control theory and experience with controlling mechanical systems {J-696}. For example, he demanded additional ‘restrictions’ from the customer, and enquired about the typical dimensions and weight of the processed paper roll {J-697, J-699}.
Another issue that was not mentioned in the initial brief but was attended to during the refinement of the initial frame was the expected initialisation of the process {J-700}. He pointed out that it was highly probable that the system might require manual start-up, for instance in the form of feeding the paper through the assembly to the output roll {J-703}. This proposal did not appear to be very important, however. More important consequence was that a similar situation might occur at the end of the process. Thus, he articulated the need to monitor when the paper at the input roll is ‘running out’, so that the system could halt in time before tearing the paper from the input roll {J-704}.