Page 1 ! ! " # $ $ $ $ $ $ $ # $ % $ $ $ & '( ) * +( ) % & $ '( , - ! Page 2 ...

14 downloads 0 Views 13MB Size Report
[A.W. Roscoe 1995] has proposed “Failures-Divergences Refinement” (FDR), ...... [Erik Simmons 2005] defines the usage model as the one that describes the.
   

                                                                                !    !  "  #    $ $    $  $    $             $        $ #   $       %       $                 $     $  

     

     &   '( )* +( )  % &$  '(     ,- 

     

  !

         

     

      

    ! 

     

    

 



  ! 

"#"#$%#&&  

                                   

 !      "        #      $  !%  !      &  $   '      '    ($     '   # %  % )   % *   % '   $  '      +      " %        &  '  !#       $,  ( $        -     .                                      !   "-           (    %                              .          %     %   %   %    $        $ $ -           -                           - - // $$$    0   1"1"#23."         

4& )*5/ +)     678%99:::&  %  ) 2  ; !   *   &        :7 /- ?7>:94& )*5/ +) "3   "    &  7>:9

TABLE OF CONTENTS ϭ͘Ϭ/EdZKhd/KE

ϳ

ϭ͘ϭ/EdZKhd/KEdK>EZKKD^K&dtZE'/EZ/E'  ϭ͘ϭ͘ϭ&/E/d/KE^EdZD/EK>K'z ϭ͘ϭ͘Ϯ/&z>WZK^^^  ϭ͘ϭ͘ϳ͘ϭDĂŶĂŐĞŵĞŶƚWƌŽĐĞƐƐĞƐ ϭ͘ϭ͘ϳ͘ϮůĞĂŶƌŽŽŵ^ƉĞĐŝĨŝĐĂƚŝŽŶWƌŽĐĞƐƐĞƐ ϭ͘ϭ͘ϳ͘ϯůĞĂŶƌŽŽŵĚĞǀĞůŽƉŵĞŶƚƉƌŽĐĞƐƐ ϭ͘ϭ͘ϳ͘ϰůĞĂŶƌŽŽŵĞƌƚŝĨŝĐĂƚŝŽŶWƌŽĐĞƐƐ  ϭ͘Ϯ/EdZKhd/KEdKD^z^dD^  ϭ͘Ϯ͘ϭ&/E/d/KE^EdZD/EK>K'z ϭ͘Ϯ͘Ϯ,ZdZ/^d/^K&D^z^dD^ ϭ͘Ϯ͘ϯ,>>E'^K&D^z^dD^ ϭ͘Ϯ͘ϰd,>/&z>DK>K&D^z^dD^ ϭ͘Ϯ͘ϱZYh/ZDEdE'/EZ/E'K&D^z^dD^ ϭ͘Ϯ͘ϲE>z^/^E^/'E/E'K&D^z^dD^  ϭ͘Ϯ͘ϳd,D^z^dDs>KWDEdWZK^^DK>^  ϭ͘Ϯ͘ϳ͘ϭdŚĞŵďĞĚĚĞĚ^LJƐƚĞŵ^ŽĨƚǁĂƌĞĞǀĞůŽƉŵĞŶƚWƌŽĐĞƐƐ ϭ͘Ϯ͘ϳ͘Ϯ,ĂƌĚǁĂƌĞĚĞǀĞůŽƉŵĞŶƚƉƌŽĐĞƐƐ  ϭ͘Ϯ͘ϴ&KZD>sZ/&/d/KE ϭ͘Ϯ͘ϵd^d/E'D^z^dD^ʹ/^^h^  ϭ͘Ϯ͘ϵ͘ϭdĞƐƚĂďŝůŝƚLJŽĨŵďĞĚĚĞĚ^LJƐƚĞŵ^ŽĨƚǁĂƌĞ

1

ϳ ϳ ϭϰ ϭϰ ϭϰ ϭϱ ϭϲ ϭϴ Ϯϵ Ϯϵ ϯϭ ϯϯ ϯϰ ϯϱ ϯϱ ϯϳ ϯϵ ϰϬ ϰϮ ϰϮ ϰϱ ϰϲ ϰϳ ϰϳ ϱϯ ϱϵ ϱϵ ϲϭ ϲϮ ϲϯ ϲϯ

ϭ͘Ϯ͘ϵ͘ϮdŚĞ^dĞƐƚŝŶŐ^ƚƌĂƚĞŐŝĞƐ ϭ͘Ϯ͘ϵ͘ϯ^dĞƐƚŝŶŐWŚĂƐĞƐ ϭ͘Ϯ͘ϵ͘ϰdŚĞ^sĞƌŝĨŝĐĂƚŝŽŶdĞƐƚŝŶŐdLJƉĞƐ ϭ͘Ϯ͘ϵ͘ϱdŚĞ^sĂůŝĚĂƚŝŽŶdĞƐƚŝŶŐDĞƚŚŽĚƐ ϭ͘Ϯ͘ϵ͘ϲdŚĞŶĞĞĚĨŽƌsĞƌŝĨŝĐĂƚŝŽŶĂŶĚsĂůŝĚĂƚŝŽŶŽĨŵďĞĚĚĞĚƐLJƐƚĞŵƐ  ϭ͘ϯZ>sEK&d,h^'K&d,>EZKKD^K&dtZE'/EZ/E'DK>^dK D^z^dD^E'/EZ/E'DK>^  ϭ͘ϯ͘ϭZ>sEK&,/ZZ,/>Ky^dZhdhZDK>/E' ϭ͘ϯ͘ϮZ>sEt/d,Z&ZEdKydZE>,s/KZDK>/E' ϭ͘ϯ͘ϯZ>sEt/d,Z&ZEdK^d/Dh>h^^YhE^ ϭ͘ϯ͘ϰZ>sEt/d,Z&ZEdK/EdZE>,s/KZ ϭ͘ϯ͘ϱZ>sEK&K'EZd/KEd,ZKh',>ZKy ϭ͘ϯ͘ϲZ>sEK&sZ/&/d/KEEs>/d/KEdsZz^d'K&s>KWDEd ϭ͘ϯ͘ϳd,Z>sEK&^dd/^d/>h^d^d/E'Ed,Z>//>/dzs>hd/KE ϭ͘ϯ͘ϴd,Z>sEK&/EZDEd>E/dZd/ss>KWDEd  ϭ͘ϰWZK>D&/E/d/KE ϭ͘ϱ^KW ϭ͘ϲ>/D/dd/KE^ ϭ͘ϳ^hDDZz

ϲϯ ϲϰ ϲϰ ϲϲ ϲϳ

ϲϴ ϲϴ ϲϵ ϲϵ ϳϬ ϳϭ ϳϭ ϳϭ ϳϮ ϳϮ ϳϯ ϳϰ ϳϰ

Ϯ͘Ϭ/EdZKhd/KEdKW/>KdWZK:ddDEZ^;dDWZdhZDKE/dKZ/E' EKEdZK>>/E'K&Eh>ZZdKZ^z^dDͿ ϳϲ Ϯ͘ϭKsZs/tK&dDEZ^  Ϯ͘ϮZYh/ZDEd^^W/&/d/KE^K&dDEZ^  Ϯ͘Ϯ͘ϭdZ'd^ZYh/ZDEd^  Ϯ͘Ϯ͘ϭ͘ϭ,ĂƌĚǁĂƌĞZĞƋƵŝƌĞŵĞŶƚƐ Ϯ͘Ϯ͘ϭ͘Ϯ,ĂƌĚǁĂƌĞ/ŶƚĞƌĨĂĐŝŶŐZĞƋƵŝƌĞŵĞŶƚƐ Ϯ͘Ϯ͘ϭ͘ϯ^ŽĨƚǁĂƌĞZĞƋƵŝƌĞŵĞŶƚƐĂƚƚŚĞdĂƌŐĞƚ^ŝĚĞ Ϯ͘Ϯ͘ϭ͘ϰKƉĞƌĂƚŝŽŶĂůZĞƋƵŝƌĞŵĞŶƚƐŽĨdDEZ^ĂƚdĂƌŐĞƚ  Ϯ͘Ϯ͘ϮZYh/ZDEd^&KZD,E/>^dhW&KZ/EdZ&/E't/d,dZ'd Ϯ͘Ϯ͘ϯ&hEd/KE>ZYh/ZDEd^K&dDEZ^d,K^d Ϯ͘Ϯ͘ϰ/EdZ&/E'ZYh/ZDEd^dtEdZ'dE,K^d  Ϯ͘ϯdDEZ^^/'E^W/&/d/KE  Ϯ͘ϯ͘ϭdZ'd^/^/'E  Ϯ͘ϯ͘ϭ͘ϭ,ĂƌĚǁĂƌĞĞƐŝŐŶĂƚdĂƌŐĞƚ Ϯ͘ϯ͘ϭ͘Ϯ^ŽĨƚǁĂƌĞĞƐŝŐŶĂƚdĂƌŐĞƚ  Ϯ͘ϯ͘Ϯ,K^d^^/'E

2

ϳϲ ϳϳ ϳϳ ϳϴ ϴϬ ϴϭ ϴϮ ϴϯ ϴϯ ϴϰ ϴϱ ϴϱ ϴϱ ϴϲ ϴϳ

Ϯ͘ϯ͘Ϯ͘ϭ^ŽĨƚǁĂƌĞŽŵƉŽŶĞŶƚĞƐŝŐŶĂƚ,K^d Ϯ͘ϯ͘Ϯ͘Ϯ,K^dďĂƐĞĚhƐĞƌ/ŶƚĞƌĨĂĐĞĞƐŝŐŶ Ϯ͘ϯ͘ϯ^K&dtZZ,/ddhZ^/'EKE^/Z/E'd,dZ'dEd,,K^d  Ϯ͘ϯ͘ϰD,E/>^dhW^/'E^W/&/d/KE Ϯ͘ϯ͘ϱh^^^/'Edd,dZ'dE,K^d Ϯ͘ϯ͘ϲ^YhE&>Kt^W/&/d/KE Ϯ͘ϯ͘ϳ^dddZE^/d/KE^/'E  Ϯ͘ϯ͘ϴdZ'd͕D,E/>^dhWE,K^d/Ed'Zd/KE^/'E^W/&/d/KEdd, ,ZtZ>s>  Ϯ͘ϯ͘ϴ͘ϭ/ŶƚĞŐƌĂƚŝŶŐƚŚĞdĂƌŐĞƚǁŝƚŚ,K^dĂƚ,ĂƌĚǁĂƌĞ>ĞǀĞů Ϯ͘ϯ͘ϴ͘Ϯ/ŶƚĞŐƌĂƚŝŶŐƚŚĞdĂƌŐĞƚǁŝƚŚDĞĐŚĂŶŝĐĂůƐĞƚƵƉĂƚ,ĂƌĚǁĂƌĞ>ĞǀĞů Ϯ͘ϯ͘ϴ͘ϯƌĐŚŝƚĞĐƚƵƌĞĞƐŝŐŶĨŽƌ,ĂƌĚǁĂƌĞ/ŶƚĞŐƌĂƚŝŽŶ  Ϯ͘ϰ^hDDZzEKE>h^/KE^

ϴϳ ϴϵ ϵϬ ϵϭ ϵϮ ϵϰ ϵϱ

ϵϲ ϵϲ ϵϳ ϵϳ ϵϴ

ϯ͘ϬDK>/E'ydZE>,s/KZK&D^z^dD^d,ZKh',>ZWZ^Edd/KE ϭϬϮ ϭϬϯ ϯ͘ϱDK>^&KZ^/'E/E'd,>/E'>>/d/KEK&D^z^dD^d,ZKh',>Dd,K^&KZsZ/&/d/KEEs>/d/KEK&>/E^Wd/KEEt>h^ͲZ^WKE^^YhE&ZKDd,WZ^Wd/sK&^d/Dh>h^

3

WZE ϭϰϬ ϯ͘ϭϭ͘ϯ>'KZ/d,D&KZ'EZd/E'd,^d/Dh>h^ͲZ^WKE^^YhE^&ZKDd,WZ^Wd/s K&d,/Ed,ZWZE ϭϰϯ ϯ͘ϭϭ͘ϰsZ/&/d/KEEs>/d/KEK&>h^ͲZ^WKE^^YhE^&ZKDϮEh^^DK>^ ϭϰϲ ϯ͘ϭϭ͘ϱ'EZd/E'd,^d/Dh>h^ͲZ^WKE^ZYh/ZDEd^&ZKDϮDK>^ ϭϰϲ ϭϱϮ ϯ͘ϭϭ͘ϲ'EZd/E'd,^d/Dh>h^ͲZ^WKE^ZYh/ZDEd^&ZKDh^^DK>^  ϯ͘ϭϮ/DWZKs/^>EZKKD^K&dtZE'/EZ/E'DK>Z>d/E'dKDK>/E' ϭϱϳ ydZE>,s/KZ ϭϱϵ ϯ͘ϭϯKE>h^/KE^ ϰ͘ϬDK>/E'/EdZE>,s/KZ>K&D^z^dD^d,ZKh',^dd Ky^dZhdhZ^ ϭϲϭ ϰ͘ϭ&/E/d/KEK&^ddKy ϰ͘ϮZWZ^Edd/KEK&^ddKy  ϰ͘ϯ^/'E/E'K&^ddKy^  ϰ͘ϯ͘ϭ^/'E/E'K&^ddKy&ZKDd^dZd/KE^ ϰ͘ϯ͘Ϯ^/'E/E'K&^ddKy^&ZKD/DW>DEdd/KEd/>^K&KEZdd ^dZhdhZ^ ϰ͘ϯ͘ϯZ/s/E'^ddKy&ZKD>^^^ ϰ͘ϰ͘ϯ'EZd/KEK&^YhE/'ZD^ ϰ͘ϰ͘ϰDK>/E'/EdZE>,s/KZd,ZKh',^dd/'ZD^h^/E'^YhE/'ZD^  ϰ͘ϱsZ/&/d/KEEs>/d/KEK&^ddKy^  ϰ͘ϱ͘ϭsZ/&//>/dzK&d,^ddKy^t/d,Z&ZEdK>z^/'E  ϰ͘ϲsZ/&/d/KE&ZDtKZEZKKD^K&dtZE'/EZ/E'Dd,KK>K'zd,ZKh',^dKy DK>^ ϰ͘ϴKE>h^/KE^ ϱ͘Ϭ/DW>DEd/E'd,D^z^dD^d,ZKh',>ZKy^ ϱ͘ϭ>ZKy&/E/d/KE  ϱ͘Ϯ^/'E/E'd,>ZKy

ϭϲϭ ϭϲϭ ϭϲϭ ϭϲϮ ϭϲϮ ϭϲϮ ϭϲϯ ϭϲϲ ϭϳϮ ϭϳϮ ϭϵϬ ϮϬϰ ϮϮϭ ϮϮϮ ϮϮϮ ϮϮϰ Ϯϯϭ ϮϯϮ Ϯϯϯ Ϯϯϯ Ϯϯϯ

4

 ϱ͘Ϯ͘ϭ^/'EK&>ZKyd,ZKh',d^dZd/KE^ ϱ͘Ϯ͘Ϯ^/'E/E'>ZKy^h^/E'KEdZK>^dZhdhZ^͗  ϱ͘ϯK'EZd/KEʹZ>dtKZddK DWW>/d/KEϮϵϯ ϱ͘ϳ͘ϮK'EZd/KE&ZDtKZEZKKD^K&dtZE'/EZ/E'Dd,KK>K'z ϱ͘ϴKE>h^/KE^ ϯϴϱ ϲ͘Ϭd^d/E'D^z^dD^d,ZKh',Z^ ϲ͘ϭd,Z&/EZ^DK>d/>>>ZKy^d' ϲ͘ϮKsZs/tKEh^'DK>^ ϲ͘ϯDK>^^dd/^d/>d^d/E' ϲ͘ϰKsZs/tKEDZ/dzK&Z^DK>^&KZd^d/E'D^z^dD^  ϲ͘ϭϮKDWZ,E^/sd^d/E'K&D^z^dD^ ϲ͘ϭϯd,Z&/E>EZKKD^K&dtZE'/EZ/E'Dd,KK>K'zt/d,Z^WddK d^d/E'D^z^dD^ ϲ͘ϭϰd^d^'EZd/KEd,ZKh',KDWZ,E^/sd^d^'EZd/KEDd,K ϲ͘ϭϱd^d/E'dDEZ^d,ZKh',KDWZ,E^/sd^d/E'Dd,K

5

ϯϴϳ ϯϴϳ ϯϴϴ ϯϵϳ ϯϵϵ ϰϬϬ ϰϬϰ ϰϬϰ ϰϬϱ ϰϬϱ ϰϬϲ ϰϬϲ ϰϬϲ ϰϬϳ ϰϭϭ ϰϭϮ ϰϭϯ ϰϭϰ ϰϰϭ

ϲ͘ϭϱ͘ϭd^dZ^h>d^^KEd,Dd,K͗^&&K>/E' ϲ͘ϭϱ͘Ϯd^dZ^h>d^^KEd,Dd,K͗^^ZdDZK^ ϲ͘ϭϱ͘ϯd^dZ^h>d^^KEd,Dd,K͗^/Dh>d/KE ϲ͘ϭϱ͘ϰd^dZ^h>d^^KEd,Dd,K͗d,/ZWZdzdKK>^ ϲ͘ϭϱ͘ϱd^dZ^h>d^^KEd,Dd,K͗>K'/E>zZ ϲ͘ϭϱ͘ϲd^dZ^h>d^^KEd,Dd,K͗/EͲ/Zh/dDh>dKZ ϲ͘ϭϱ͘ϳd^dZ^h>d^^KEd,Dd,K͗DKE/dKZ^ ϲ͘ϭϲZd/&/d/KE ϲ͘ϭϳ^hDDZzEKE>h^/KE^

ϰϰϮ ϰϰϳ ϰϰϵ ϰϱϰ ϰϱϴ ϰϲϮ ϰϲϰ ϰϲϳ ϰϲϳ

ϳ͘Ϭ^hDDZzEKE>h^/KE^

ϰϲϵ

ϴ͘Ϭ&hdhZtKZ Ref. Temp-1 Pump-1 is started by triggering the Relay If the Temp-1 Ref. Temp-2 Pump-2 is started by triggering the Relay If the Temp-2< =Ref. Temp-2 Pump-2 is stopped by switching off the Relay If ABS (Temp-1 ± Temp-2) > 2 :ULWH D PHVVDJH ³7HPS 0LVPDWFK´ RQ LCD. If ABS (Temp-1 ± Temp-2) > 2 Switch on the Buzzer If ABS (Temp-1 ± Temp-2) 2

Related Responses

Preceding Stimulus

RS1 RS2 RS3 ST1 RS4 ST2 RS5 ST3 RS6 ST4 RS7 ST5 RS8/ {RS9,RS10, RS11} RS12 ST6 RS13 ST7 RS14 ST8 Rs16 RS18/RS19 Rs15 ST8 Rs17 RS20/21 RS22, ST9 {RS23/RS24} ST10

or

TABLE 3.5 Mapping of the stimuli with responses and Stimulus Precedence Step-2 Map the Stimuli to Requirements Identify various stimuli that are related to the requirements projected by the user. Table 3.4 shows the mapping between the requirements and the stimulus. Some of the requirements may not be directly related to the stimulus. Step-3 Identify responses from TMCNRS The responses that must be obtained from the TMCNRS are identified by studying all the requirements carefully. Table 3.4 shows the expected responses from TMCNRS. Step-4 MAP the responses to the Stimuli The responses from the TMCNRS are due to the consequence of occurrence of stimuli. The mapping of the stimuli with responses is shown in the Table 3.5. One event (stimulus) may produce more than one response. Step-5 Generate Stimulus-Responses in Canonical form Generate all the valid stimulus sequences straight away derived into canonical form using the following sub-steps and Table 3.5. Table 3.6 shows the stimulus Sequences that are generated.

142

1. Identify the starting stimulus based on the precedence relationship between the stimuli. The stimulus that has no parent is the first stimulus. 2. Trace the stimulus sequence based on the precedence relationship until a response is generated and report the sequence. 3. Continue Step 5 (2) until the last stimulus is traced. The stimulus that is not a parent to any other stimulus is the last stimulus. The algorithm is simple and utilizes the precedence relationship between the stimuli. The stimulus-response sequences generated are straight away in canonical form and the need for exhaustive enumeration and reduction as stated by [S. J. Prowell and J. H. Poore 2003] is not required, thus simplifying the procedure for obtaining the stimulus-response sequences. Stimulus Sequence No. 1 2 3 4 5 6

7 8 9 10 11 12

Stimulus Sequence

Response generated

ST1 ST1, ST2 ST1, ST2, ST3 ST1, ST2, ST3, ST4 ST1, ST2, ST3, ST4, ST5 ST1, ST2, ST3, ST4, ST5, ST6

RS1, RS2 RS3 RS4 RS5 RS6 RS7, RS8/ {RS9,RS10, RS11} RS12 RS13 RS14, RS16, RS18/RS19 RS22, {RS23/RS24}

ST1, ST2, ST3, ST4, ST5, ST6, ST7 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, ST9 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, ST9, ST11 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, ST10 RS15,RS17,RS20/RS21 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, RS22, {RS23/RS24} ST10, ST11 Table 3.6 Sequences of Stimulus-Responses

3.11.3 Algorithm for generating the Stimulus-Response Sequences from the perspective of Thin Thread Precedence Step-1 Map the Stimuli to Thin Threads A stimulus causes a thin thread and a thin thread provides END-TO-END processing and produces a response. A thin thread may be caused in sequence to the execution of another thin thread, thus connecting the thin threads through precedence logic. Also, a set of thin threads may be initiated in two parallel sequences. The mapping of the thin threads to the stimuli and the precedence that exists among

143

the thin threads is shown in the Table 3.7. The data related to mapping can be generated by way of modeling the thin threads through graphic tools S. No.

1

Thin Thread Number TH1

2

TH2

3

TH3

4

TH4

5

TH5

6

TH6

7

TH7

8

TH8

9

TH9

10 11 12 13 14

TH10 TH11 TH12 TH13 TH14

15

TH15

16

TH16

Thin Thread Description

Related Stimulus

Processing of Temp-1 and ST9 producing output on LCD Processing of Temp-1 and ST9 transmitting to HOST Processing of Temp-1 and ST9, Starting Pump-1 ST15 if Temp-1 > Ref. Temp-1 or Stopping Pump-1 if Temp-1 < = Ref. Temp-1 Processing of Temp-2 and ST10 producing output on LCD Processing of Temp-2 and ST10 transmitting to HOST Processing of Temp-2 and ST10, Starting Pump-2 ST16 if Temp-2 > Ref. Temp-2 or Stopping Pump-2 if Temp-2 < = Ref. Temp-2 Comparing Temp-1 and Temp-2 and ST11 reporting the mismatch on LCD Comparing Temp-1 and Temp-2 and ST11 Trigger a Buzzer if a mismatch occurs; Else de-trigger the buzzer if the mismatch does not occur Reset the Application and ST1 produce messages on the LCD regarding the Application Title and Request for Entry of Password Press Key-1 and display * on LCD ST2 Press Key-2 and display * on LCD ST3 Press Key-3 and display * on LCD ST4 Press Key-4 and display * on LCD ST5 Press Key-5 and display * on LCD ST6 and display a series of messages on LCD regarding the mismatch of the password and request for obtaining Ref. Temp-1 and Ref. Temp-2 Read Ref. Temp-1 from Host and ST7 display the same on LCD Read Ref. Temp-2 from Host and ST8 display the same on LCD Table 3.7 Mapping of Stimulus to Thin Threads

144

Preceding Thin Thread

TH1 TH2

TH4 TH5

TH6 TH7

TH9 TH10 TH11 TH12 TH13

TH14 TH15

The entire processing of an embedded system can be presented by way of developing precedence relationships among the thin threads. The starting thin thread has no parent thin thread and the ending thin thread is not a parent to any of the thin threads.

Step-2 Generate Stimulus-Response Sequences One can generate all the valid Stimulus-response sequences straight away derived in canonical form by using the mapping between the thin thread, stimuli and responses. Table 3.6 shows the stimulus-response sequences that are generated using the following substeps: a) Identify the starting thin thread that has no parent and consider it as the preceding thin thread. b) Identify the Stimulus associated with the thin thread, and enter the stimulus into a Stimulus sequence buffer. c) Find if there is an associated response for the stimulus from Table 3.5. If a Response exists, report the stimulus-response sequence as valid sequence. Find the next thin thread (Current thin thread) for which the preceding thin thread is the parent d) Check whether the stimulus associated with the current thin thread is same as the previous thin thread e) If stimuli are the same, then ignore the current thin thread f) If the current stimulus is different from the previous stimulus and if the current stimulus has associated response, then include the stimulus into stimulus sequence and report stimulus-response sequence g) If the current stimulus is different from the previous stimulus and if the current stimulus has no associated response, then include the stimulus into stimulus sequence h) Let current thin thread be previous Thin Thread and the current stimulus as previous stimulus. i)

Read the next thin thread.

j)

If the next thin thread has no parent and if it has an associated stimulus which has a related response, then include the stimulus into stimulus sequence and into stimulus- response sequence and report.

k) If the next thin thread has a parent, then make the next thin thread as the current thin thread and then move to step (e)

145

Both the algorithms have generated the same stimulus-response sequences as reported in Table 3.6 by using the perspectives of precedence between the stimuli and the thin threads. Thus, the verification of the requirements with the Black Box structures is undertaken by generating stimulus-response sequences in two ways (Thin Thread precedence and Stimulus precedence) and proving that the stimulus-response sequences are the same.

3.11.4 Verification and validation of Black Box structures through the generation of stimulus-response sequences from E2E and Use Case models [Sastry J.K.R, Chandra Prakash V. and

L.S.S. Reddy, 2009-2] have presented

additional verification frameworks to verify and validate the stimulus-response sequences derived through END-TO-END processing and Use Case models again proving that the Stimulus-Response sequences generated are the same when they same are generated using the E2E and Use Case Models. They have used the thin thread framework for generating the stimulus-response sequences and compared the same with the Stimulus-response sequences that are generated directly from the requirement specification. The verification and validation of Black Boxes have been presented considering generation of the stimulus sequences from two perspectives.

3.11.5 Generating the Stimulus-Response requirements from E2E models The following algorithm generates Stimulus-Response Sequence from Thin Threads Step-1 Identify the stimuli from requirements specification The requirements specification of the TMCNRS is studied and all the stimuli that trigger different functions are noted which are shown in the Table 3.8. The sequence in which the stimuli should happen is important and therefore it is necessary to study the relationships between them. The relationships between the stimuli are built using the precedence logic. The precedence relationships between the stimuli are shown in the Table 3.8 Stimulus Label ST1 ST2 ST3 ST4

Stimulus Description

Previous Stimulus

A reset to the Microcontroller for starting the Embedded Application Pressing 1st Key on the Key Board Pressing 2nd Key on the Key Board Pressing 3rd Key on the Key Board

146

ST1 ST2 ST3

ST5 Pressing 4th Key on the Key Board ST4 ST6 Pressing 5th Key on the Key Board ST5 ST7 Ref. Temp-1 from HOST ST6 ST8 Ref. Temp-2 from HOST ST7 ST9 Temp-1 from Sensor-1 ST8 ST10 Temp-2 from Sensor-2 ST8 ST11 ABS (Temp-1 ± Temp-2) > 2 ST9 or ST10 Table 3.8 Precedence relationships between the stimuli of TMCNRS Step-2 Map the Stimuli to Requirements Identify various stimuli that are related to the requirements projected by the user. Table 3.9 shows the mapping between the requirements and the stimulus. Some of the Requirements may not be directly related to the stimulus. Serial Number 1 2 3

4

5

6

7

8 9 10

Functional requirements

Related Stimulus On reset, TMCNRS must display a message (Title of the ST1 Application) on LCD On Reset, Prompt for Password Entry must be displayed ST1 on the LCD On pressing 1st Key an * must be displayed on the LCD ST2 retaining the Key value in the memory. The key pressed should be one of A-F and 0-9 On pressing 2nd Key an * must be displayed on the LCD ST3 retaining the Key value in the memory. The key pressed should be one of A-F and 0-9 On pressing 3rd Key an * must be displayed on the LCD ST4 retaining the Key value in the memory. The key pressed should be one of A-F and 0-9 On pressing 4th Key an * must be displayed on the LCD ST5 retaining the Key value in the memory. The key pressed should be one of A-F and 0-9 On pressing 5th Key an * must be displayed on the LCD ST6 retaining the Key value in the memory. The key pressed should be one of A-F and 0-9. if the Entered password is invalid, a message must be displayed on the LCD and a prompt must be displayed to enter the password once again. Else display a Message on the LCD to Input Reference Temperatures. Read Ref. Temp-1 from the HOST and store the same in the memory Read Ref. Temp-2 from the HOST and store the same in the memory Sense Temp-1 once in 10 milliseconds, display the same on LCD and send the Temp-1 to HOST. If the Temp-1 sensed > Ref. Temp-1, then the Relay connected to the Pump-1 must be

147

ST7 ST18 ST9

activated; else deactivated 11 After sensing the Temp-1, Sense Temp-2 after 10 ST10 milliseconds and display the same on LCD and send the Temp-2 to HOST If the Temp-2 sensed > Ref. Temp-2, then the Relay connected to the Pump-2 must be activated; else deactivated. 12 If ABS (Temp-1 ± Temp-2) > 2, then Assert the Buzzer; ST11 else de-assert the Buzzer. Table 3.9 Mapping of Stimuli to Functional requirements related to TMCNRS Step-3 Identify the responses that should be generated by the application The responses that must be obtained from the TMCNRS are identified by studying all the requirements carefully. Table 3.10 shows the expected responses from TMCNRS. Response Label RS1 RS2 RS3 RS4 RS5 RS6 RS7 RS8 RS9 RS10 RS11 RS12 RS13 RS14 RS15 RS16 RS17 RS18 RS19 RS20 RS21 RS22

Response Description Display Application Title Display a message for inputting the password Display a single * Display a single * Display a single * Display a single * Display a single * Display Invalid Message if password does not tally Prompt a message on LCD for obtaining Reference Temperatures from HOST Request to HOST for Ref. Temp-1 Request to HOST for Ref. Temp-2 Display the Ref. Temp-1 on LCD Display the Ref. Temp-2 on LCD The sensed Temp-1 is communicated to the HOST The sensed Temp-2 is communicated to the HOST Write Temp-1 to LCD Write Temp-2 to LCD The Pump-1 is started by triggering the Relay if the Temp-1 > Ref. Temp-1 The Pump-1 is stopped by switching off the Relay if the Temp-1< =Ref. Temp-1 The Pump-2 is started by triggering the Relay if the Temp-2 > Ref. Temp-2 The Pump-2 is stopped by switching off the Relay if the Temp-2< =Ref. Temp-2 If ABS (Temp-1 ± Temp-2) > 2 :ULWHD0HVVDJH³7HPSHUDWXUH0LVPDWFK´RQ/&'

148

RS23 RS24

If ABS (Temp-1 ± Temp-2) > 2, then Switch on the Buzzer If ABS (Temp-1 ± Temp-2) 2 RS22, {RS23/RS24} Table 3.11 Mapping of the stimuli with responses

Step-5 Map the Stimulus-Response Sequences to Thin Threads A stimulus causes a thin thread and a thin thread provides END-TO-END processing and produces a response. A thin thread may be caused in sequence to the execution of another thin thread, thus connecting the thin threads through precedence logic. Also, a set of thin threads may be initiated in two parallel sequences. The mapping of the thin threads to the stimuli and the precedence that exists among the thin threads is shown in the Table 3.12. The entire processing of an embedded system can be presented by way of developing precedence relationships among the thin threads. The starting thin thread has no parent thin thread and the ending thin thread is not a parent to any of the thin threads.

149

S. No. Thin Thread Number 1 TH1 2 3

4 5 6

7 8

9

10 11 12 13 14

15 16

Thin Thread Description

Related Stimulus

Processing of Temp -1 and ST9 producing an LCD output TH2 Processing of Temp -1 and ST9 transmitting To HOST TH3 Processing of Temp-1 and starting ST9, Pump-1 if Temp-1 > Ref.Temp-1 and ST15 Stopping Pump-1 if Temp-1 < Ref.Temp-1 TH4 Processing of Temp -2 and producing ST10 an LCD output TH5 Processing of Temp -2 and transmitting ST10 To HOST TH6 Processing of Temp-2 and starting ST10, Pump-2 if Temp-2 > Ref.Temp-2 or ST16 stopping Pump-2 if Temp-2 < Ref.Temp-2 TH7 Comparing Temp-1 and Temp-2 and ST11 reporting the Mismatch on LCD TH8 Comparing Temp-1 and Temp-2 and ST11 Trigger a Buzzer if a Mismatch occurs else de-trigger the buzzer if the mismatch does not occur TH9 Reset the Application and produce ST1 messages on the LCD regarding the Application Title and the Request for Entry of Password TH10 Press Key-1 and display * on LCD ST2 TH11 Press Key-2 and display * on LCD ST3 TH12 Press Key-3 and display * on LCD ST4 TH13 Press Key-4 and display * on LCD ST5 TH14 Press Key-5 and display * on LCD and ST6 display series of messages on LCD regarding the mismatch of the password, and request for obtaining of the Ref. Temp-1 and Ref. Temp-2 TH15 Read Ref.Temp-1 from HOST and ST7 display the same on LCD TH16 Read Ref.Temp-2 from HOST and ST8 display the same on LCD Table 3.12 Mapping of stimulus to the Thin Threads

Preceding Thin Threads

TH1 TH2

TH4 TH5

TH6 TH7

TH9 TH10 TH11 TH12 TH13

TH14 TH15

Step-6 Execute Algorithm-1 and generate the stimulus-response sequence A Stimulus Sequence is the sequence in which the stimuli can occur and the Stimulus Sequence will become Stimulus-Response Sequence when the response generated by the last stimulus is added to the Stimulus-Sequence. Using Algorithm-1 and the Table 3.12,

150

one can generate all the valid Stimulus-Response Sequences straight away derived into Canonical form. Table 3.13 shows the Stimulus Sequences that are generated using the Algorithm-1. Algorithm-1 1. Identify the starting thin thread that has no parent and consider it as the preceding thin thread. 2. Identify the Stimulus associated with the thin thread, and enter the stimulus into a Stimulus sequence buffer. 3. Find if there is an associated response for the stimulus from Table 3.11. If a Response exists, report the Stimulus-Response Sequence as one valid sequence. 4. Find the next thin thread (Current thin thread) for which the preceding thin thread is the parent. 5. Check whether the stimulus associated with the current thin thread is same as the previous thin thread 6. If stimuli are the same, then ignore the current thin thread 7. If the current stimulus is different from the previous stimulus and if the current stimulus has associated response, then include the stimulus into Stimulus Sequence and report Stimulus-Response Sequence 8. If the current stimulus is different from the previous stimulus and if the current stimulus has no associated response, then include the stimulus into Stimulus Sequence 9. Let current thin thread be previous Thin Thread and the current stimulus as previous stimulus. 10. Read the next thin thread. 11. If the next thin thread has no parent and if it has an associated stimulus which has a related response, then include the stimulus into Stimulus Sequence and into Stimulus- Response Sequence and report. 12. If the next thin thread has a parent then make the next thin thread as the current thin thread and move to step-3. Stimulus Sequence Number 1 2 3 4 5 6 7 8 9

Stimulus Sequence

Response generated

ST1 ST1, ST2 ST1, ST2, ST3 ST1, ST2, ST3, ST4 ST1, ST2, ST3, ST4, ST5 ST1, ST2, ST3, ST4, ST5, ST6

RS1, RS2 RS3 RS4 RS5 RS6 RS7, RS8/{RS9,RS10, RS11} ST1, ST2, ST3, ST4, ST5, ST6, ST7 RS12 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8 RS13 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, RS14, RS16, ST9 RS18/RS19

151

10 11 12

ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, RS22, {RS23/RS24} ST9, ST11 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, RS15,RS17,RS20/RS21 ST10 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, RS22, {RS23/RS24} ST10, ST11 Table 3.13 Sequences of Stimulus-Responses

3.11.6 Generating the Stimulus-Response requirements from Use Case models The following algorithm is used to generate the Stimulus-Response sequences from Use Case models Step-1 Develop the Use Case models from the functional requirements. Any number of Use Case diagrams can be drawn to depict different flows in the system. For the TMCNRS, two Use Case Diagrams have been drawn (1) for initialization and authentication and (2) for processing the Temperatures. The diagrams have been shown in the Figures 3.33 and 3.34. The operator interacts with the TMCNRS for authentication through keyboard entries and display of authentication on LCD. The HOST cooperating system interacts with TMCNRS for inputting the Reference Temperatures and also to receive the Temperatures being sensed on different sampling rates from time to time. The temperature sensors as cooperating systems also interact with the TMCNRS for supplying the sensed Temperatures. Fig. 3.33 shows the interaction of the operator for authentication purposes and Fig. 3.34 shows the interaction of the Temperature sensors and the HOST system that facilitate the processing of the Temperatures.

152

RS1 ST1

Reset ST2

Operator

RS2

ST3 Process KEY-1 ST5



RS3

ST4

ST6 Process KEY-2

RS4





Process KEY-4 Process KEY-3

RS5

Process KEY-5 RS6

RS7

{Only when Password Mismatch Occurs}

RS8

RS11

RS9

RS10

Fig. 3.33 User Interaction for authentication and start of the Application

153



ST7

RS10 RS16

HOST

Read Ref 1 Temp

ST9

RS12



{When Temp-1 > Ref Temp-1}

Read Temp1

Temp-1 Sensor

Compare Temp-1 with Ref1

RS18

{When Temp1 Ref Temp2}

RS20

Read Ref Temp 2

Compare Temp 2 with Ref2

{When Temp2 Ref. Temp1 UC30 Stop the Pump-1 if Temp-1 is < Ref. Temp-1 UC31 Compare Temp-2 with Ref. Temp-2

nd UC25

155

UC32 Start the Pump-2 RS20 UC31 Exte 9, 11 if Temp-1 > Ref. Tempnd 2 UC33 Stop the Pump-2 RS21 UC31 Extend 9, 11 If Temp-1 is < Ref. Temp-2 UC34 Compute UC25, Include 1 UC22 2 ABS (Temp-1 ± Temp2) UC35 :ULWH³0LVPDWFK$%6 RS22 UC34 Extend 1 (Temp-1 ± Temp-2) 2 !´RQ/&' UC36 Trigger the Buzzer if ST11 RS23 UC34 Extend 1 ABS (Temp-1 ± Temp2 2) > 2 UC37 De-trigger the Buzzer if ST11 RS24 UC34 Extend 1 2 ABS (Temp-1 ± Temp2) > 2 Table 3.14 Relationships between the Use Cases, Functional requirements and the Stimulus-Response Step-3 Generate the Stimulus-Response Sequence using the following Algorithm Start with the Use Case which is associated with a stimulus and not having a preceding Use case. Include the stimulus into a Queue. LABEL RESPONSE: If the Use Case produces a response or responses as an extension Logic, then report the Stimulus Sequence from the queue with response being produced LOOP RESPONSE LABEL XYZ: Move on to the succeeding Stimulus by following the precedence Trace and enter the stimulus into the queue. LABEL RESPONSE1: If the Use Case produces a response or responses as extension logic, then report the stimulus sequence from the queue with the response being produced LOOP RESPONSE1: LOOP XYZ The Stimulus-Response Sequences generated by the above algorithm are shown in the Table 3.15 below:

156

Stimulus Sequence Number 1 2 3 4 5 6 7 8 9 10 11 12

Stimulus Sequence

Response generated

ST1 ST1, ST2 ST1, ST2, ST3 ST1, ST2, ST3, ST4 ST1, ST2, ST3, ST4, ST5 ST1, ST2, ST3, ST4, ST5, ST6

RS1, RS2 RS3 RS4 RS5 RS6 RS7, RS8/{RS9, RS10, RS11} ST1, ST2, ST3, ST4, ST5, ST6, ST7 RS12 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8 RS13 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, RS14, RS16, RS18/RS19 ST9 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, RS22, {RS23/RS24} ST9, ST11 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, RS15, RS17, RS20/RS21 ST10 ST1, ST2, ST3, ST4, ST5, ST6, ST7, ST8, RS22, {RS23/RS24} ST10, ST11 Table 3.15 Sequences of Stimulus-Responses

Verify and validate It could be seen that the Stimulus-Response Sequences generated and shown in the Table 3.15 based on Use Cases using the above algorithm are exactly same as the sequences generated based on the precedence relationships among thin thread shown in the Table 3. 13. Thus, it can be construed that the External behavioral requirements of the intended system are properly modeled.

3.12 Improvised Clean Room Software Engineering Model relating to modeling external behavior In Chapter 1, the Clean Room Software Engineering Life Cycle Model has been described. Fig. 3.35 briefly explains the CRSE process Model Functional Requirements

External Behavior V&V of Specification Black Box (Black Box Models Structure)

State Box Models

V&V of V&V of Clear Box State Box Clear Box Models Models Models

Requirements Specification

Test Process Certfication Models Models

Usage Requirements

Usage Models

Probability Models

Test Case Models (SUT)

Fig. 3.35 Clean Room Software Engineering Process Model

157

The original CRSE methodology claims that only formal methods be used for modeling any of the models stated in the Fig 3.35 so that any of the specifications is accurate and one specification is traceable from the other, especially in the Design flow (top flow) and the Testing flow (bottom flow). The formal methods specified are mathematical in nature and therefore not feasible for usage and implementation. The Z and B notations used for representing the specifications mathematically found to be Composite and not easily implementable. No automatic development process has ever been considered by the CRSE. The V&V methods suggested to verify and validate one model with the other are not Formal and most of the methods suggested are traditional and classical. Most of the V&V methods suggested are manual in nature, thus loosing the formal nature of the CRSE model. In this thesis, more emphasis is laid for formalizing and automating every model. Several of the refinements to the original CRSE model have been carried to formalize the modeling of the external behavior trough Black Box Structures. From the above figure 3.35, it could be seen that no scientific basis is used for identifying the Black Box structures from the Functional specifications derived from the Requirements specification. The Identification of external behavior through Black Box structure is truly intuitive or based on the experiences gained through development of many such systems. The quality of the entire system is very much dependent on the proper identification and development of Black Box Structures. The refined CRSE model considering the issue of formalism and automation is shown in the Fig. 3.36 State Box Structures

Functional Requirements

External Behavior Specification (Black Box Model) Formalism through E2E Model

V&V of V&V of Clear Box State Box Clear Box Structures Structures Structures

V&V of Black Box Models Stimulus E2E Use case Precedence Precedence Models Models Model

Requirements Specification

Test ProcessCertfication Models Models

Stimulus Response Models

Usage Requirements

Usage Models

Probability Models

Test Case Models (SUT)

Fig. 3.36 Refined CRSE Model for Refining the BB Structures

158

The External behavior modeling and verification of the same with respect to requirements have been formalized and various models that help automating the formalism have been suggested in this chapter. The BB structures have been formalized through End-To-END processing models. E2E processing requirements of the embedded systems clearly help in identifying appropriate Black Box structures as the thin threads provides the general flow of processing, thus revealing the sequence of occurrence of the stimulus leading to response. E2E requirements are derived from the Functional Requirements as E2E processing requirements alone will clearly state the way the events are processed till the final control function is carried. The E2E processing requirements will clearly lay the basis for modeling the external behavior of the system. In this chapter, two verification and validation models for validating BB models have been presented. The verification and validation of BB is primarily achieved through Stimulus Response models. The Stimulus-Response models can be derived from various perspectives that include stimulus precedence, E2E precedence and the Use Case models. The V&V framework models have been presented that use a pair of models that together use the Stimulus-Response model. Framework-1 considers the Stimulus precedence and E2E precedence and the verification and validation is done through Stimulus-Response Sequences. Framework-2 considers the E2E precedence and Use Case models that together generated Stimulus-Response Sequences. The verification and validation is done by proving that the same Stimulus-Response is generated by all the models, there by showing their equivalences.

3.13 Conclusions In this chapter, it has been emphasized that, though CRSE has advocated the Formalism for modeling the external behavior and also for verifying and validating the same with reference to the functional requirements, no models have ever been presented that are formal, implementable and automated. The models suggested are mathematical in nature and application of the same is rather Composite and impracticable. There is a need to identify models that formalize the BB and its verification and validation models. Five different models have been proposed that help in formalizing and automating the design of external behavioral modeling. The models proposed use the UML artifacts as the UML is a formal language using which the formalism is implemented. The modeling of BB structures has been proposed based on the E2E processing models and the verification and validation of the same is undertaken through Use Case models

159

and Stimulus-Response precedence models. The models are built around a Repository System and algorithms that generate models depicting external behavior modeling The models proposed have been proved by applying the same to the pilot project TMCNRS and the formalism and automation implemented by the models have been proved. The models proposed have called for refinements in BB structuring and verification. The refinements proposed are reflected in the CRSE model and the refined model has been presented.

160

 0RGHOLQJ ,QWHUQDO %HKDYLRUDO RI (PEHGGHG 6\VWHPV WKURXJK6WDWH%R[VWUXFWXUHV 4.1 Definition of State Box The State Box (SB) gives an intermediate view that defines an internal state which is an abstraction of the data stored from stimulus to response. A State Box is a Black Box (BB) that takes external stimulus and changes its internal state to a new state and gives an external response. [Michel Deck et al. 1996] defines the state of any program at any instant is mapping from variables to values. The state space of a program is a set of all possible mappings from variables to values. The behavior of a program is defined by state space mapping domain and its range of the program. [Snehamay Bandyopadhyay et al. 1988] describes the State Box (State Machine) as an intermediate view that defines an internal state which is an abstraction of the data stored due to occurrence of stimuli. [Harlan D. Mills 1988] defines that for a coherent system a State Box is given by Black Box transition function from histories of pairs (stimulus, state) to response pairs (response, state), where a state is an encapsulation of the stimulus history. A state can represent stimulus histories in many different ways. The State Box transition function can vary with state representation.

4.2 Representation of State Box The internal behavior of any system can be modeled through a set of State Boxes that can be represented in a hierarchical structure. A State Box in which there are a finite number of states is called a Finite State Machine. A finite Black Box can be represented by a Finite State Machine because the encapsulation can be a finite number of stimulus histories of the order of the Black Box, but a Finite State Machine need not have finite Black Box representation.

4.3 Designing of State Boxes State Boxes are designed from different perspectives by different authors in the literature. Some presentations have also been made to verify and validate the designed State Boxes. Clean Room Software Engineering (CRSE) advocates that a State Box (SB) must be verified and validated with reference to a Black Box. The following sub sections present the methods, processes and models that are used to develop the SB. The methods, processes and models, as such, do not recommend any formal frameworks for designing the internal behavior of a system using State Boxes.

161

4.3.1 Designing of State Box from Data abstractions [Harlan D. Mills 1988] has described a methodology for constructing the State Boxes wiWKWKHKHOSRIGDWDDEVWUDFWLRQV7KHWHUP³GDWDDEVWUDFWLRQ´LPSOLHVWKHSRVVLELOLW\RI storing data between stimuli to respond to the effects of previous stimulus. The principle of information hiding requires that the data is required as a response at a later operation be regarded as part of an abstract state of the data abstraction, which may be implemented in various ways and always provides a correct description of the behavior. There is a simple mathematical way to guarantee the existence of such a state and the correct behavior of an abstraction with it by regarding the stimulus history itself as the state. Then, for each stimulus, a black-box function is used to compute the response from the stimulus history including the current stimulus received. The new state is computed by appending the current stimulus to the previous state. This construction defines a State Machine which is infinite state machine as the stimulus histories are not bounded. The data abstractions have mapping functions that map the unbounded set of stimulus histories to a finite set of new state representations leading to a Finite State Machine that represents the Black Box behavior. However, the classical state machine, in which the state transition is a mathematical function from stimuli and old states to response and new state, has a serious deficiency in elaborating system behavior in a hierarchical structure. Such transition function forces all VWDWHGDWDLQWRWKHVWDWHPDFKLQH¶VVWDWHWHUPLQDWLQJWKHKLHUDUFK\RIVWDWHGDWDVWorage. A State Box uses a data abstraction to determine the next state and response for each stimulus.

4.3.2 Designing of State Boxes from implementation details of concrete data structures [Michel Deck et al. 1996] have stated that the State Box is the first step of implementing the data specification of Black Box. In the State Box, different aspects of implementation of concrete data structures are considered which include state data and process specification that operates on the data. The abstract models thus are restated in terms of the state data. Thus, the state data objects are instances of Black Box data specifications. The state model exists in real programming sense and the state data have initial values.

4.3.3 Deriving State Box from Black Box [Michel Deck et al. 1996] have recommended that the State Boxes be derived directly

162

from the Black Boxes by way of implementing abstract data models. A state Box can be derived out of the elementary level black boxes that are in the hierarchy. A State Box can be represented as a as a hierarchy of states and this hierarchy is generally called as Usage Hierarchy since the relationship between BB and SB is determined by usage of one specification by another. The hierarchy also defines a dependency relationship. When a change is made at implementation level, a re-review at the higher level (BB) must also be undertaken.

4.3.4 Deriving the State Boxes from Use Cases [Louis Gomes et al. 2003] have proposed a method for deriving the State Charts from Use Cases. They have considered computational requirements of Reactive Embedded Systems as the basis for representing the functional requirements as a set of State Boxes. The computational model of a Reactive System must support concurrency and sequential processing and it also must support the communication through different interfaces between the concurrent components that form the system. The computational model must also support the representation of the system as hierarchical models such as State Boxes. The perceptions of different users related to functional requirements of the system are considered and the perceptions of the users are hierarchically organized and for each of the perception Use Case diagrams are drawn. State charts are both specification and implementation models. They help in modeling the internal behavior of the system. State charts are graphical formalisms based on the state of the systems plus the notations of hierarchy, parallelism and communication between the parallel sub-systems. State charts implement two refinements which include XOR refinement and AND refinement. The XOR refinement implements the hierarchy through encapsulation of the state machines. The AND refinement implements the concurrent execution of the XOR components. The state machines thus can have three different types of components which include the regular state, a set associated with AND, and a Cluster associated with XOR. The default state shall take the control of the system when the system is initially initiated. A machine transits from one state to other and each of the transitions is designated by the event that caused the transition and the condition upon which the transition has taken place. As a consequence, to a Transition taking place, due to internal events output can be generated irrespective of History (Mealy Machine) or the output generated may also depend on the History events (Moore machine). The transitions can trigger special events such as Entered event or Exited event. Entered event is triggered when a machine enters into a state. Exited event is triggered when a Machine exits from a state. The transitions

163

can also be designated with special conditions such as in (state) and special actions such as clear history (state) or deep clear history (state). Clear history or deep clear history will FOHDUWKHKLVWRU\SUHVHUYHGLQWKHFOXVWHU³VWDWH´ State charts also presents a concept called History. The history supports the modeling of interrupts which allow the context restoring after processing of the interrupt is completed. This concept can be implemented using the clusters. When a machine enters into a cluster with a state and history attribute, the state that will be active upon entrance will be the state to get control when exiting is done from the cluster. The default state will be the active state when a machine enters into a cluster. The semantics to the state charts can be added through a Step algorithm and criteria. The Step algorithms dictate the way the system evolves between two states. Simultaneous triggering of finite set of transitions is called the Micro-step. A Step is a set of Microsteps. Transitions fired in a Micro-step can trigger internal events that, in turn, can fire other transitions. The criteria help in resolving the conflicting transitions by way of selecting right transitions among the conflicting transitions. External events are not considered while the system is in either a step or micro-step, which means that while one external event is being processed, no other external event can be processed. This is a serious limitation when it comes to Highly Reactive Systems. Each Use Case is presented as a state chart having several sub-charts that behave in parallel. Each sub-chart will behave concurrently. Each of the sub-charts shall be considered as a component that can be mapped to either hardware or software or Hardware-Software type of components. Initial sub-chart shall be decomposed based on certain rules and each of the sub-charts shall behave concurrently. This is called model partitioning. One can try several iterations of partitioning and each partition is computed in terms of price and performance. Each sub-module produced can be implemented using one of the implementation platforms. When several concurrent sub-charts are implemented, the communication between the sub-charts must be considered. A default communication system can be identified at the initial model itself. The default communication system could be stated to be implemented using either a Global clock or by implementing Globally Asynchronous and Locally Synchronous Systems. A state chart can be partitioned into a set of communicating state charts. The communicating state charts can be represented as a Cluster with one AND set and several XOR state charts. The AND set is isomorphic with initial state diagram. The partitioning algorithm based on a logic can partition a state chart into many that together form a set.

164

Partitioning of the State Chart A top level state diagram can be partitioned by recognizing the existence of two diagrams interconnected with one arc or existences of more number of sub-diagrams with variable number of arcs. When the state chart decomposed into two state charts, then a node (state) is added to each of the diagrams which provide an entry into other. When more number of active components in the state diagram exist, individual state charts are drawn for each of the active components and more states are added into each of the state chart equivalent to the number of inter-connections that should be established. Default state is elected according to the default state of the initial diagram and the arcs that connect one diagram to the other will include an activation condition. In this kind of partitioning, clear-cut identification of the decomposed state diagrams related to hardware or software or hardware-software is not considered. Implementation of State Charts The state chart diagrams, thus, are hierarchically decomposed. The issue of implementation of the state charts lies in the decision of choosing a state chart diagram or the state space of the diagram. The state diagram may be used to implement tasks meant for specifications, simulation and verification where as the state space may be used to implement other non-proprietary based tasks. The implementation of the tasks can be undertaken based on the state space either directly or indirectly. While the direct implementation is based on the state chart components, indirect implementation is based on previous translation of the start chart into state space. 7ZRRIWKHWRROV³67$7(0$7(´>'. +DUHOHWDO@DQG³5KDSVRG\´ [Rhapsody, 2004] use the direct implementation which is based on the translation of state chart components. The direct implementation of state chart components can be carried using the switch statements, classes (State Chart), Class hierarchy (State Chart Hierarchy), Table (Runtime object structure) as defined in the UML. The implementation strategies, however, do not take into consideration the hardware, software and the combination components. Direct implementation of state charts does not help the implementation of concurrency either at hardware or software level. One of the strategies is to implement the state charts using both the direct and indirect implementation. [Louis Gomes et al. 2003] have proposed a balanced approach which includes direct implementation and handling the issues related to communication, hierarchical refinements, concurrency, and parallelism at higher level of the state charts. Several translation procedures are suggested that lift the issues related to concurrency and

165

communication to the higher levels of the state chart hierarchy. Moreover, the components will be identified such that the implementation of the state charts can be achieved in terms of hardware, software or both. [Louis Gomes et al. 2003] have dealt with the issue of concurrency of execution of various components identified at the state chart diagram level which is a decomposition of the functions that are related to a Use Case. However, in the Co-design of an embedded system, more important issues related to implementation at the hardware, software and hardware-software level and the partition of state chart should use the criteria related to implementation at the hardware, software and hardware-software level. Even the issues such as response, scheduling and reliability must be taken into account so that event based processing can be implemented. Optimization of the performance at the code level both in case of hardware and software must also be addressed and possibly provide the reverse engineering based on the optimized code to represent the application. [Chandra Prakash V., Dr. Sastry JKR and DBK Kamesh, 2011-3] have proposed a formal framework using which the internal behavirol modeling of the embedded systems can be made. State Models as proposed in the CRSE methodology has been considered in the framework for internal behavirol modeling.

4.4 Formal Framework for designing State Box The object models and Class diagrams defined in the unified methodology help tracing the internal behavior of any system. The Class diagrams provide a formal framework for representing the structural behavior of any system. Class diagrams can be used as the basis for tracing the internal behavior of any system. The functional requirements of a system can be revisited and the objects that derive a system can be identified and drawn into a diagram duly depicting the relationships, attributes, and behaviors. From the functional requirements, various objects which are either hardware or software can be identified. The process diagrams (Thin thread diagrams that we have discussed in the chapter 3) can be used as the basis for identifying the hardware and software components and the kind of relationships that exist between them. UML 2.0 has been used to identify the objects related to TMCNRS system. The relationships between the classes can also be depicted through UML Class diagrams. Various processing sequences that exist in the TMCNRS have been identified and for each of the processing sequences a separate Class diagram has been drawn. The diagrams have been presented in the Figure 4.1 to Figure 4.4. The interaction between the classes that undertake the initialization of TMCNRS is

166

shown in the Fig 4.1. The classes and the interaction between the classes for Temperature1 (Temp-1) processing, Temperature-2 (Temp-2) Processing and comparison of Temperatures are shown in Figures 4.2, 4.3 and 4.4

167

4.4.1 Development of Repository of Classes The UML Class diagrams can be used to capture the type of the object, properties of the object and various behavioral aspects. A data repository for the objects can be developed. Data models help in forward and backward engineering of the graph-based models such as Class diagrams. The data repository captured for TMCNRS related classes is shown in the Table 4.1. The attributes that are essential for scheduling, sequencing, prioritizing, response time, object type, etc. shall be captured through Class diagrams and the same will be maintained in a data repository. The relationships between the classes and the direction of relationships between the classes can be shown in the UML Class diagrams. The relationships between the hardware objects, software objects and in between the hardware objects and the software objects can also be shown in the Class diagrams. The actors that initiate external events at an object can also be shown in the Class diagrams duly codifying the event with a label on the line connecting the objects. The data repository related to the relationships among the classes, the direction of the relationships, the external events that are triggered through the stimulus, the internal events that are triggered due to an external stimulus are maintained as shown in the Table 4.1. The repository can be captured and maintained based on the UML 2.0 Class diagrams.

4.4.2 Identifying the Data/Signal flows among the Classes The data flows and signal flows that exist among the classes can be determined with the help of event initiation data that has been captured into data repository which includes the relationship data. The relationship data between the components is shown in the Table 4.2. The relationships between the hardware components are shown as the Interface components and the same are shown in the components list shown in Table 4.1

172

Micro Controller

HOST

LCD

3

4

Reset Button

Name of the Component

2

Serial Number of the Object 1

H

H

H

H

173

Type of component (H- hardware, S-Software) char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][]

Attributes

Displaydevice()

Displaydevice()

Displaydevice()

Displaydevice()

Functions

A/D Converter

Key Board

Temp-1 Sensor

Temp-2 Sensor

5

6

7

8

H

H

H

H

174

int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] Displaydevice()

Displaydevice()

Displaydevice()

Displaydevice()

Operational Amplifier-1

Operational Amplifier-2

Buzzer

10

11

Name of the Component

Serial Number of the Object 9

H

H

175

Type of component (H- hardware, S-Software) H char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][]

Attributes

Displaydevice()

Displaydevice()

Displaydevice()

Functions

Pump-1

Pump-2

Relay-1

Pump1

13

14

15

Name of the Component

Serial Number of the Object 12

H

H

H

H

176

Type of component (H- hardware, S-Software) char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][]

Attributes

Displaydevice()

Displaydevice()

Displaydevice()

Displaydevice()

Functions

Relay-2

Pump-2

Process Key

Validate Password

Process LCD

Initialization Process

17

18

19

20

21

Name of the Component

Serial Number of the Object 16

S

S

S

S

H

H

Type of component (H- hardware, S-Software)

177

float latency Sbit rs= p3^5 Sbit rw=p3^4 Sbit en=p3^3 Sbit busy=p2^7 char Component Type float latency

char Component Type float latency int passwdsta=0 char Component Type

char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type float latency char device-model int number-of-ports int number-of-pins int type-of-pins[][] int type-of-signal[][] int type-of-value[][] char Component Type int key-count=5 float latency

Attributes

Void displayInitMessage() Void displayEnterPasswdMessage() Void readRefTemp() Void convertRefDigitsToValues()

Void data_write() Void bussycheck()

Void command_write()

Void readkey() friend i2c-read-temp() friend i2c-write-temp() friend i2c-strat-temp() friend i2c0stop-temp Int comparepasswd()

Displaydevice()

Displaydevice()

Functions

Temp-1 Task

Temp-2 Task

24

Process HOST

Name of the Component

23

Serial Number of the Object 22

S

S

178

Type of component (H- hardware, S-Software) S char Component Type float latency Sbit SBUF = ^P4 char Component Type float latency Int priority = 100 Unsigned digit0, digit, digit1 Unsigned ascii0, ascii1, ascii2 Unsigned char ref1_at_0x21 Unsigned char array9[]= ³7(03(5$785( &´ OS_STK Temp1TaskStk(3000) char Component Type float latency Int priority = 100 Unsigned digit0, digit, digit1 Unsigned ascii0, ascii1, ascii2 Unsigned char ref2_at_0x21 Unsigned char array10[]= ³7(03(5$785( &´ OS_STK Temp2TaskStk(3000)

Attributes

Void delay()

Void getReferencsValues()

Void hex2Ascii() Void ascii2Hex()

Void getReferencsValues() Void delay() Void processTemp2Task() friend i2c-read-temp() friend i2c-write-temp() friend i2c-strat-temp() friend i2c0stop-temp

Void hexToAscii() Void asciiToHex()

Void processTemp1Task() friend i2c-read-temp() friend i2c-write-temp() friend i2c-strat-temp() friend i2c0stop-temp

Void send() Void recv()

Functions

Compare Temp-2 with Reference Temperature-2 (Ref.Temp2, Ref-2)

Process Temp-1 and Temp-2Task

ProcessBuzzer

27

28

Compare Temp-1 with Reference Temperature-1 (Ref.Temp1, Ref-1)

Name of the Component

26

Serial Number of the Object 25

S

S

S

S

179

Type of component (H- hardware, S-Software)

float latency Chat t1 Char ref1 OS_STK CompareTemp2TaskSTk (3000) char Component Type float latency Float priority = 200 OS_STK ProcessTemp1Temp2Task (3000) Unsigned char i Unsigned char diff Unsigned char array10[]= ³0,60$7&+´ Unsigned code array[] Unsigned char Temperature1[2] Unsigned char Temperature[2] char Component Type float latency Sbit buzzer P2^3

float latency Chat t1 Char ref1 OS_STK CompareTemp1TaskSTk (3000) char Component Type

char Component Type

Attributes

compareTemp1Temp2Task() Void Delay()

compareTemp2withRef2(Char char rref2) Friend void hex2Ascii() Delay()

compareTemp1withRef1(Char char rref1) Friend void hex2Ascii() Delay()

Functions

tt1,

tt1,

MC-Relay1

MC-Relay2

Relay1-Pump1

Relay2-Pump2

Temp1-OPT1

Temp2-OPT2

OPT1-ATOD

35

36

37

38

39

40

41

MC-LCD

ATOD-MC

34

44

MC-Buzzer

33

OPT2-ATOD

Keybaord-ATOD

32

MC-HOST

Rest-MC

31

43

ProcessPump2

30

42

ProcessPump1

Name of the Component

Serial Number of the Object 29

Attributes

180

Sbit pump1 = P2^3 char Component Type float latency S Sbit pump1 = P2^3 char Component Type float latency HI Int reset-Interface[][] Int MC-Interface[][] HI Int KeyBaord-Interface[][] Int ATOD-Interface[][] HI Int Buzzer-Interface[][] Int MC-Interface[][] HI Int ATOD-Interface[][] Int MC-Interface[][] HI Int Relay1-Interface[][] Int MC-Interface[][] HI Int Relay2-Interface[][] Int MC-Interface[][] HI Int Relay1-Interface[][] Int Pump1-Interface[][] HI Int Relay2-Interface[][] Int Pump2-Interface[][] HI Int Temp1-Interface[][] Int OPT1-Interface[][] HI Int Temp2-Interface[][] Int OPT2-Interface[][] HI Int ATOD-Interface[][] Int OPT1-Interface[][] HI Int ATOD-Interface[][] Int OPT2-Interface[][] HI Int HOST-Interface[][] Int MC-Interface[][] HI Int HOST-Interface[][] Int MC-Interface[][] Table 4.1 Data Repository for TMCNRS based objects

S

Type of component (H- hardware, S-Software)

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

displayConnections(0

Functions

LCD A/D Converter

Key Board

Temp- Sensor

4 5

6

7

H

H

H H

H

H H

Reset Button Micro Controller

HOST

Type of component (H-Hardware, SSoftware)

Name of the Component

3

Serial Number of Compon ent 1 2

Temp-2 Task

181

Communicate with Host Process LCD Process Key Temp-1 Task

Preceding Software components

Micro Controller Key Board Operational Amplifier-1 Operational Amplifier-2

Reset Button A/D Converter HOST Micro Controller

Preceding Hardware Components

Internal/External

1. Sense Temp-1 and display on LCD 2. Sense Temp-1 and send to HOST 3. Sense Temp-1 and compare with Ref.Temp-1

Enter Key

1. Read Ref. Temp-1 2. Read Ref. Temp-2

Reset

Associated Event

ST2 ST3 ST4 ST5 ST6 ST9

ST7 ST8

ST1

Event code

Pump-1 Pump-2 Relay-1

Relay-2

Process Key

Validate Password

12 13 14

15

16

17

S

S

H

H H H

H H H

H

Temp-2 Sensor

Operational Amplifier-1 Operational Amplifier-2 Buzzer

Type of component (H- hardware, SSoftware)

Name of the Component

9 10 11

Serial Number of Compon ent 8

with

with

182

Relay-1 Relay-2 Compare Temp-1 Ref.Temp-1 Compare Temp-2 Ref.Temp-2 Initialization Process Initialization Process

Process Buzzer

Preceding Software components

Micro Controller

Micro Controller

Temp-1 Sensor Temp-2 Sensor Micro Controller

Preceding Hardware Components

1. Sense Temp-2 and display on LCD 2. Sense Temp-2 and send to HOST 3. Sense Temp-2 and compare with Ref.Temp-2

Associated Internal/External Event

RS23 RS24

ST10

Event code

Temp-2 Task

Compare Temp-1 with Ref.Temp-1 Compare Temp-2 with Ref.Temp-2

22

23

24

Temp-1 Task

21

with

Communication HOST

20

S

S

S

S

S

S

S

Process LCD

Initialization Process

Type of component (H- hardware, SSoftware)

Name of the Component

19

Serial Number of Compon ent 18

Temp-2 Task

Temp-1Task

Initialization Process Temp-1 Task Temp-2 Task

183

Initialization Process Validate Password Temp-1Task Temp-2 Task Communicate with HOST Process Temp-1 and Temp-2 Task

Preceding Software components

Micro Controller A/D Converter Micro Controller A/D Converter

HOST

Micro Controller

Preceding Hardware Components

Associated Internal/External Event

RS18 RS19

Event code

26

Serial Number of Compo nent 25

Process Buzzer

Process Temp-1 and Temp-2

Preceding Software components

Micro Controller

Preceding Hardware Components

2.

ST11 ST12

1.

Process Temp-1 and Temp-2 and write on LCD Process Temp-1 and Temp-2 and assert /De assert Buzzer

Event code

Associated Internal/External Event

184

Table 4.2 Relationships between the Hardware and Software Components

S

S

and

Process Temp-2

Temp-1

Type of component (H- hardware, S-Software)

Name of the Component

Algorithm for determining the Data/Signal Flows among the components Identify the starting points of Data flow by identifying the components that have no preceding components and having stimulus input. For each of the stimuli identified (Event), add a column to the Flow Graph Matrix { For each of the starting components, develop a Flow Graph Matrix having rows equivalent to the succeeding components provided no row exists for such a component { The presence of the component for a column is indicated through a special symbol inserted in the row column cross section The type of succeeding component is determined (backward flow or forward flow). If the succeeding component is in forward flow and is already defined and is situated prior to the current position of the component, then the component in the forward flow is relocated to be the next component in position If the succeeding component is in backward flow and is already defined and is situated prior to the current position of the component, then a replication of the component in the backward flow is created to be the next component in position

Generally, the replication of the components occurs when the same components serves both inputting and outputting process.

When the flow count of the succeeding components is more than 1, more columns are created by way of copying of the current flow and then tracing the flow further from there. } All the components are numbered in the order of the flow by using a 4 digit code where the first two digits indicate the position of the component and the next two digits indicate the component code. Appearance of

185

component code at a position which has been already referred in the previous position indicates the reverse flow.

} Each of the columns in the Flow Graph Matrix indicates a sequence flow with the object structure responsible for realizing a Use Case. The Flow Graph Matrix is shown in the Table 4.3

186

Communication with HOST

Micro Controller Initialization Process Validate process

0909

1010 1111 1212

Temp-2-Task

Compare Temp-1 with Ref.Temp-1 Compare Temp-2 with Ref.Temp-2 Process Temp-1 and Temp-2 Process LCD

LCD

Validation process Initialization Process Communication with HOST HOST Process Buzzer Buzzer Relay-1 Pump-1 Relay-2 Pump-2

1515

1616 1717 1818 1919

2020

2112 2211 2309 2408 2525 2626 2727 2828 2929 3030

Process Key

HOST

0808

Temp-1 Task

A/D Converter

0707

1414

Operational Amplifier-2

0606

1313

Temp-2 Sensor

Operational Amplifier-1

0505

0303

0404

Key Board

Temp-1 Sensor

0202

Reset Button Wait-1

Name of the Component

0101 0102

Serial Number of Compon ent

S S S H S H H H H H

H

S S S S

S

S

S

H S S

S

H

H

H

H

H

H

H

H

187

Type of component (H- hardware, S-Software)

¥ ¥

¥

¥

¥ ¥

¥

¥

Press Key-1 to Key5

¥

¥ ¥

¥

Push Reset Button ST1

¥ ¥

¥

¥

¥ ¥

Validate Password

Event

¥

¥

¥

Request for Inputting Ref. Temps

¥

¥

¥

¥

¥

Read Ref. Temp-1

HOST Communication with HOST

0808 0909

Process Key

Temp-1 Task

Temp-2-Task

Compare Temp-1 with Ref.Temp-1 Compare Temp-2 with Ref.Temp-2 Process Temp-1 and Temp-2 Process LCD LCD Validation process Initialization process Communication with HOST HOST Process Buzzer Buzzer Relay-1 Pump-1 Relay-2 Pump-2

1313

1414

1515

1616 1717 1818 1919 2020 2112 2211 2309 2408 2525 2626 2727 2828 2929 3030

Micro Controller

A/D Converter

0707

Initialization Process Validate Password

Operational Amplifier-2

0606

1111 1212

Operational Amplifier-1

0505

1010

Reset Button Wait-1 Key Board Temp-1Sensor Temp-2 Sensor

Name of the Component

0101 0102 0202 0303 0404

Serial Number of Compone nt

S S S S H S S S H S H H H H H

S

S

S

S S

H

H S

H

H

H

H H H

H

Type of component (H- hardware, S-Software)

¥ ¥

¥

¥ ¥

188

Read Temp-2

Ref.

Event

¥ ¥

¥

¥

¥ ¥

¥

¥

¥

¥

¥ ¥

¥

¥

Read Temp-1 and send to HOST

¥

¥

Read Temp-1 and Display on LCD

¥ ¥

¥

¥

¥

¥

¥

¥

¥

Read Temp-1 and process Pump-1

¥ ¥

¥

¥

¥

¥

¥

Read Temp-2 and Display on LCD

¥

S

189

Temp-2-Task

S

Compare Temp-1 with Ref.Temp-1 S Compare Temp-2 with Ref.Temp-2 S ¥ Process Temp-1 and Temp-2 S ¥ Process LCD S LCD H Validation process S Initialization process S Communication with HOST S ¥ HOST H ¥ Process Buzzer S ¥ Buzzer H ¥ Relay-1 H Pump-1 H Relay-2 H ¥ Pump-2 H ¥ Table 4.3 Data Flows and signal flows modeling for TMCNRS based on the Class diagrams

¥

¥

¥

¥

¥

1616 1717 1818 1919 2020 2112 2211 2309 2408 2525 2626 2727 2828 2929 3030

¥

1515

¥

Event Compare Temp-1 and Temp-2 and assert Buzzer

Process Key

S

¥

¥

¥

¥

¥

¥

¥

¥

¥

Read Temp-2 and process Pump-2

Temp-1 Task

¥

Read Temp-2 to HOST

1414

S S

H

S

H

H

H H H H

H

H

Type of component (H- hardware, S-Software)

1313

Initialization Process Validate Password

1111 1212

HOST

0808

Communication with HOST

A/D Converter

0707

Micro Controller

Temp-1 Sensor Temp-2 Sensor Operational Amplifier-1 Operational Amplifier-2

0303 0404 0505 0606

1010

Key Board

0202

0909

Reset Button Wait-1

Name of the Component

0101 0102

Serial Number of Compone nt ¥

¥ ¥ ¥

¥

¥

¥

¥

¥

Compare Temp-1 & Temp-2 and write on LCD

¥ ¥

¥ ¥

¥

Send request to host for Ref. Temperatures

4.4.3 Generation of Sequence diagrams Each of the flows in the Table 4.3 represents a flow of execution through interaction of several components which are ordered in a chronological sequence and the order depicts the flow of execution when an event occurs. Each sequence of execution will lead to realization of a Use Case which is used for modeling the external behavior of the embedded system. There are different flows for the TMCNRS and all these flows can be automatically identified and the sequence diagrams drawn for each of the flows are shown in the Figures 4.5

to

4.18

Initialisation Process :

Process LCD : LCD :

Micro Controller :

Operator : Reset

Reset Call

Initialisation Message Enter Password Message Enter Password Message

)LJ6HTXHQFHIORZIRUWKH(YHQW³3XVK5HVHWEXWWRQ´

190

Intilisation Process Key Board :

ATODConverter :

ProcessLCD

ProcessKey

Micro Controller :

Key Signal Key Data Read Key() process Key Write Key Display Key

Loop for Next Key (5)

Fig 4.6 Processing Key pressed for entering the password

191

LCD

Initialisation Process

Validate Password :

Process LCD :

LCD :

Call Processpswd()

Invalid Password Write Password Mismatch Invalid Password

Fig 4.7 Validate Password

192

Initialisation Process

Process LCD :

LCD :

Requestng for inputting Refrence Temps

Request Message reference temparatuers

Fig. 4.8 Request for Inputting Reference Temperatures

193

HOST :

Process HOST :

Initialisation Process :

REF-1 Request Message REF-1 Request Message

REF-1 Data Comm read/write Status

Fig. 4.9 Read Ref. Temp-1

194

ProcessLCD

LCD

ProcessLCD Initialisation Process :

Process HOST :

HOST :

REF-2 Request Message REF-2 Request Message REF-2 Data Read/unread status

Fig 4.10 Read Ref. Temp-2

195

LCD

Temp1Sensor :

Temp2 Sensor :

Temparatuer Sensor-1 : num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class ResetButton extends HWDevice {

262

float latency; int num-of-ports, int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; ResetButton ( ) { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³5HVHW%XWWRQ´  while (fis !null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class OperationalAmplifier1 extends HWDevice { float latency; int num-of-ports, int num-of-pins;

263

char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; OperationalAmplifier1 ( ) { FileInputStream fis = FileInputStream ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³2SHUDWLRQDO$PSOLILHU´  while (fis !null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class OperationalAmplifier2 extends HWDevice { float latency; int num-of-ports, int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins];

264

int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; OperationalAmplifier2 ( ) { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³2SHUDWLRQDO$PSOLILHU´  while (fis !null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } }

265

Class ATODConverter extends HWDevice { float latency; int num-of-ports, int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; ATODConverter ( ) { FileInputStream fis = FileInput6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³$72'&RQYHUWHU´  while (fis! null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class TemperatureSensor2 extends HWDevice {

266

float latency; int num-of-ports, int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; TemperatureSensor2 ( ) { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³7HPSHUDWXUH6HQVRU´  while (fis !null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class KeyBoard extends HWDevice { float latency; int num-of-ports,

267

int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; KeyBaord ( ) { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\devicerHSRVLWRU\GDW´ ILVVHHN ³.H\ERDUG´ while (fis !null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class Buzzer extends HWDevice { float latency; int num-of-ports,

268

int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; Buzzer ( ) { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³%X]]HU´ while (fis !null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { Class LCD extends HWDevice { float latency; int num-of-ports, int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins];

269

LCD ( ) { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³/&'´ while (fis !null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class HOST extends HWDevice { float latency; int num-of-ports, int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; HOST( ) {

270

)LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³+267´ while (fis !null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class Relay1 extends HWDevice { float latency; int num-of-ports, int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; ILVVHHN ³5HOD\´ Relay1 ( ) { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´

271

ILVVHHN ³5HOD\´ while (fis !null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class Relay2 extends HWDevice { float latency; int num-of-ports, int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; Relay2 ( ) { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³5HOD\´ while (fis !null) {

272

fis. read (latency); fis. Read (num-of-ports}; fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class Pump1 extends HWDevice { float latency; int num-of-ports, int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; Pump1 ( ) { FileInpXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³3XPS´ while (fis !null) { fis. read (latency); fis. Read (num-of-ports};

273

fis. Read (num0of-pins); fis. read(componetType); for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class Pump2 extends HWDevice { float latency; int num-of-ports, int num-of-pins; char componetType; int type-of-pins [num-of-ports] [num-of-pins]; int type-of-signals [num-of-ports] [num-of-pins]; int type-of-values [num-of-ports] [num-of-pins]; Pump2 ( ) { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ ILVVHHN ³3XPS´  while (fis !null) { fis. read (latency); fis. Read (num-of-ports}; fis. Read (num-of-pins); fis. read(componetType);

274

for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-pins[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-signals[ii][jj]) } } for (int ii=0, ii>num-of-ports, ii++) { for (int jj=0, jj>num-of-pins, jj++) { fis.read(type-of-values[ii][jj]) } } void displayDevice () { } } Class Reset-MC ( int num-of-ports-MC, int num-of-pins-MC; int MC-Port-Num, int MC-Pin-Num; int MC-interface [num-of-ports-MC] [num-of-pins-MC]; int num-of-ports-ResetButton; int num-of-pins-ResetButton; int Reset-Port-Num, int Reset-Pin-Num; Reset-MC () { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ Fis.seek ³0LFUR&RQWUROOHU´  fis. Read (num-of-ports-MC}; fis. Read (num-of-pins-MC);

275

)LVVHHN ³5HVHW%XWWRQ´  fis. Read (num-of-ports-ResetButton}; fis. Read (num-of-pins-ResetButton); for (int ii=0, ii>num-of-ports-ResetButton, ii++) { for (int jj=0, jj>num-of-pins-ResetButton, jj++) { fis. read (MC-Port-Num); fis. read (MC-Pin-Num); fis. read (Reset-Port-Num); fis. Read (Reset-Pin-Num); MC-interface [MC-Port-Num][MC-Pin-Num] Num) } } void displayConnections ()

= Reset-Port-Num*1+Reset-Pin-

{ } } Class Keyboard-ATOD ( int num-of-ports-KEYBOARD, int num-of-pins-KEYBOARD; int KEYBOARD-Port-Num, int KEYBOARD-Pin-Num; int KEYBOARD-interface KEYBOARD]; int num-of-ports-ATOD; int num-of-pins-ATOD; int ATOD-Port-Num, int ATOD-Pin-Num;

[num-of-ports-KEYBOARD]

[num-of-pins-

ATOD-KEYBOARD () { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³.H\ERDUG´  fis. Read (num-of-ports-KEYBOARD}; fis. Read (num-of-pins-KEYBOARD); )LVVHHN ³$72'´ 

276

fis. Read (num-of-ports-ATOD}; fis. Read (num-of-pins-ATOD); for (int ii=0, ii>num-of-ports-ATOD, ii++) { for (int jj=0, jj>num-of-pins-ATOD, jj++) { fis. read (KEYBOARD-Port-Num); fis. read (KEYBOARD-Pin-Num); fis. read (ATOD-Port-Num); fis. Read (ATOD-Pin-Num); KEYBOARD-interface [KEYBOARD-Port-Num][KEYBOARD-Pin-Num] ATOD-Port-Num*1+ATOD-Pin-Num) } } void displayConnections () { }

} Class ATOD-MC ( int num-of-ports-MC, int num-of-pins-MC; int MC-Port-Num, int MC-Pin-Num; int MC-interface [num-of-ports-MC] [num-of-pins-MC]; int num-of-ports-ATOD; int num-of-pins-ATOD; int ATOD-Port-Num, int ATOD-Pin-Num; ATOD-MC () { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³0LFUR&RQWUROOHU´  fis. Read (num-of-ports-MC}; fis. Read (num-of-pins-MC); )LVVHHN ³$72'´  fis. Read (num-of-ports-ATOD}; fis. Read (num-of-pins-ATOD); for (int ii=0, ii>num-of-ports-ATOD, ii++)

277

=

{ for (int jj=0, jj>num-of-pins-ATOD, jj++) { fis. read (MC-Port-Num); fis. read (MC-Pin-Num); fis. read (ATOD-Port-Num); fis. Read (ATOD-Pin-Num); MC-interface [MC-Port-Num][MC-Pin-Num] = ATOD-Port-Num*1+ATOD-PinNum) } } void displayConnections () { } } Class MC-Buzzer ( int num-of-ports-MC, int num-of-pins-MC; int MC-Port-Num, int MC-Pin-Num; int MC-interface [num-of-ports-MC] [num-of-pins-MC]; int num-of-ports-Buzzer; int num-of-pins-Buzzer; int Buzzer-Port-Num, int Buzzer-Pin-Num; MC-Buzzer () { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ Fis.sHHN ³0LFUR&RQWUROOHU´  fis. Read (num-of-ports-MC}; fis. Read (num-of-pins-MC); )LVVHHN ³%X]]HU´  fis. Read (num-of-ports-Buzzer}; fis. Read (num-of-pins-Buzzer); for (int ii=0, ii>num-of-ports-Buzzer, ii++) { for (int jj=0, jj>num-of-pins-Buzzer, jj++) { fis. read (MC-Port-Num); fis. read (MC-Pin-Num);

278

fis. read (Buzzer-Port-Num); fis. Read (Buzzer-Pin-Num); MC-interface [MC-Port-Num][MC-Pin-Num] Num) } }

= Reset-Port-Num*1+Buzzer-Pin-

void displayConnections () { } } Class MC-LCD ( int num-of-ports-MC, int num-of-pins-MC; int MC-Port-Num, int MC-Pin-Num; int MC-interface [num-of-ports-MC] [num-of-pins-MC]; int num-of-ports-LCD; int num-of-pins-LCD; int LCD-Port-Num, int LCD-Pin-Num; MC-LCD () { FileInputStream fis = FileInput6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³0LFUR&RQWUROOHU´  fis. Read (num-of-ports-MC}; fis. Read (num-of-pins-MC); )LVVHHN ³/&'´  fis. Read (num-of-ports-LCD}; fis. Read (num-of-pins-LCD); for (int ii=0, ii>num-of-ports-LCD, ii++) { for (int jj=0, jj>num-of-pins-LCD, jj++) { fis. read (MC-Port-Num); fis. read (MC-Pin-Num); fis. read (Reset-Port-Num); fis. Read (Reset-Pin-Num);

279

MC-interface [MC-Port-Num][MC-Pin-Num] = LCD-Port-Num*1+LCD-Pin-Num) } } void displayConnections () { } } Class MC-Relay1 ( int num-of-ports-MC, int num-of-pins-MC; int MC-Port-Num, int MC-Pin-Num; int MC-interface [num-of-ports-MC] [num-of-pins-MC]; int num-of-ports-RELAY1; int num-of-pins-RELAY1; int RELAY1-Port-Num, int RELAY1-Pin-Num; MC-RELAY1 () { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³0LFUR&RQWUROOHU´  fis. Read (num-of-ports-MC}; fis. Read (num-of-pins-MC); )LVVHHN ³5(/$num-of-ports-RELAY1, ii++) { for (int jj=0, jj>num-of-pins-RELAY1, jj++) { fis. read (MC-Port-Num); fis. read (MC-Pin-Num); fis. read (Reset-Port-Num); fis. Read (Reset-Pin-Num); MC-interface [MC-Port-Num][MC-Pin-Num] = RELAY1-Port-Num*1+RELAY1Pin-Num) } } void displayConnections ()

280

{ } } Class MC-Relay2 ( int num-of-ports-MC, int num-of-pins-MC; int MC-Port-Num, int MC-Pin-Num; int MC-interface [num-of-ports-MC] [num-of-pins-MC]; int num-of-ports-RELAY2; int num-of-pins-RELAY2; int RELAY2-Port-Num, int RELAY2-Pin-Num; MC-RELAY2() { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³0LFUR&RQWUROOHU´  fis. Read (num-of-ports-MC}; fis. Read (num-of-pins-MC); Fis.seek ³5(/$num-of-ports-RELAY2, ii++) { for (int jj=0, jj>num-of-pins-RELAY2, jj++) { fis. read (MC-Port-Num); fis. read (MC-Pin-Num); fis. read (Reset-Port-Num); fis. Read (Reset-Pin-Num); MC-interface [MC-Port-Num][MC-Pin-Num] = RELAY2-Port-Num*1+RELAY2Pin-Num) } } void displayConnections () { } }

281

Class MC-HOST ( int num-of-ports-MC, int num-of-pins-MC; int MC-Port-Num, int MC-Pin-Num; int MC-interface [num-of-ports-MC] [num-of-pins-MC]; int num-of-ports-HOST; int num-of-pins-HOST; int HOST-Port-Num, int HOST-Pin-Num; MC-HOST() { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³0LFUR&RQWUROOHU´  fis. Read (num-of-ports-MC}; fis. Read (num-of-pins-MC); )LVVHHN ³+267´  fis. Read (num-of-ports-HOST}; fis. Read (num-of-pins-HOST); for (int ii=0, ii>num-of-ports-HOST, ii++) { for (int jj=0, jj>num-of-pins-HOST, jj++) { fis. read (MC-Port-Num); fis. read (MC-Pin-Num); fis. read (Reset-Port-Num); fis. Read (Reset-Pin-Num); MC-interface [MC-Port-Num][MC-Pin-Num] Pin-Num) } } void displayConnections () { } } Class SENSOR1-OPT1 ( int num-of-ports-SENSOR1, int num-of-pins-SENSOR1; int SENSOR1-Port-Num,

282

= HOST-Port-Num*1+HOST-

int SENSOR1-Pin-Num; int SENSOR1-interface [num-of-ports-SENSOR1] [num-of-pins-SENSOR1]; int num-of-ports-OPT1; int num-of-pins-OPT1; int OPT1-Port-Num, int OPT1-Pin-Num; SENSOR1-OPT1 () { FileInputStream fis = FileInputStreaP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³6HQVRU´  fis. Read (num-of-ports-SENSOR1}; fis. Read (num-of-pins-SENSOR1); )LVVHHN ³237´  fis. Read (num-of-ports-OPT1}; fis. Read (num-of-pins-OPT1); for (int ii=0, ii>num-of-ports-OPT1, ii++) { for (int jj=0, jj>num-of-pins-OPT1, jj++) { fis. read (SENSOR1-Port-Num); fis. read (SENSOR1-Pin-Num); fis. read (SENSOR1-Port-Num); fis. Read (SENSOR1-Pin-Num); SENSOR1-interface [SENSOR1-Port-Num][SENSOR1-Pin-Num] Num*1+OPT1-Pin-Num) } } void displayConnections ()

= OPT1-Port-

{ } } Class SENSOR2-OPT2 ( int num-of-ports-SENSOR2, int num-of-pins-SENSOR2; int SENSOR2-Port-Num, int SENSOR2-Pin-Num; int SENSOR2-interface [num-of-ports-SENSOR2] [num-of-pins-SENSOR2]; int num-of-ports-OPT2; int num-of-pins-OPT2; int OPT2-Port-Num,

283

int OPT2-Pin-Num; SENSOR2-OPT2 () { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³6HQVRU´  fis. Read (num-of-ports-SENSOR2}; fis. Read (num-of-pins-SENSOR2); Fis.seek ³237´  fis. Read (num-of-ports-OPT2}; fis. Read (num-of-pins-OPT2); for (int ii=0, ii>num-of-ports-OPT2, ii++) { for (int jj=0, jj>num-of-pins-OPT2, jj++) { fis. read (SENSOR2-Port-Num); fis. read (SENSOR2-Pin-Num); fis. read (SENSOR2-Port-Num); fis. Read (SENSOR2-Pin-Num); SENSOR2-interface [SENSOR2-Port-Num][SENSOR2-Pin-Num] Num*2+OPT2-Pin-Num) } } void displayConnections ()

= OPT2-Port-

{ } } Class OPT1-ATOD ( int num-of-ports-OPT1, int num-of-pins-OPT1; int OPT1-Port-Num, int OPT1-Pin-Num; int OPT1-interface [num-of-ports-OPT1] [num-of-pins-OPT1]; int num-of-ports-ATOD; int num-of-pins-ATOD; int ATOD-Port-Num, int ATOD-Pin-Num; OPT1-ATOD () { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´

284

)LVVHHN ³237´  fis. Read (num-of-ports-OPT1}; fis. Read (num-of-pins-OPT1); )LVVHHN ³$72'´  fis. Read (num-of-ports-ATOD}; fis. Read (num-of-pins-ATOD); for (int ii=0, ii>num-of-ports-ATOD, ii++) { for (int jj=0, jj>num-of-pins-ATOD, jj++) { fis. read (OPT1-Port-Num); fis. read (OPT1-Pin-Num); fis. read (OPT1-Port-Num); fis. Read (OPT1-Pin-Num); OPT1-interface [OPT1-Port-Num][OPT1-Pin-Num] = ATOD-Port-Num*2+ATODPin-Num) } } void displayConnections () { } } Class OPT2-ATOD ( int num-of-ports-OPT2, int num-of-pins-OPT2; int OPT2-Port-Num, int OPT2-Pin-Num; int OPT2-interface [num-of-ports-OPT2] [num-of-pins-OPT2]; int num-of-ports-ATOD; int num-of-pins-ATOD; int ATOD-Port-Num, int ATOD-Pin-Num; OPT2-ATOD () { FileInputStream fis = FileInpXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³237´  fis. Read (num-of-ports-OPT2}; fis. Read (num-of-pins-OPT2);

285

)LVVHHN ³$72'´  fis. Read (num-of-ports-ATOD}; fis. Read (num-of-pins-ATOD); for (int ii=0, ii>num-of-ports-ATOD, ii++) { for (int jj=0, jj>num-of-pins-ATOD, jj++) { fis. read (OPT2-Port-Num); fis. read (OPT2-Pin-Num); fis. read (OPT2-Port-Num); fis. Read (OPT2-Pin-Num); OPT2-interface [OPT2-Port-Num][OPT2-Pin-Num] = ATOD-Port-Num*2+ATODPin-Num) } } void displayConnections () { } } Class RELAY1-PUMP1 ( int num-of-ports-RELAY1, int num-of-pins-RELAY1; int RELAY1-Port-Num, int RELAY1-Pin-Num; int RELAY1-interface [num-of-ports-RELAY1] [num-of-pins-RELAY1]; int num-of-ports-PUMP1; int num-of-pins-PUMP1; int PUMP1-Port-Num, int PUMP1-Pin-Num; RELAY1-PUMP1 () { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³5(/$num-of-ports-PUMP1, ii++) { for (int jj=0, jj>num-of-pins-PUMP1, jj++) { fis. read (RELAY1-Port-Num); fis. read (RELAY1-Pin-Num); fis. read (RELAY1-Port-Num); fis. Read (RELAY1-Pin-Num); RELAY1-interface [RELAY1-Port-Num][RELAY1-Pin-Num] Num*2+PUMP1-Pin-Num) } } void displayConnections ()

= PUMP1-Port-

{ } } Class RELAY2-PUMP2 ( int num-of-ports-RELAY2, int num-of-pins-RELAY2; int RELAY2-Port-Num, int RELAY2-Pin-Num; int RELAY2-interface [num-of-ports-RELAY2] [num-of-pins-RELAY2]; int num-of-ports-PUMP2; int num-of-pins-PUMP2; int PUMP2-Port-Num, int PUMP2-Pin-Num; RELAY2-PUMP2 () { )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ )LVVHHN ³5(/$num-of-ports-PUMP2, ii++) { for (int jj=0, jj>num-of-pins-PUMP2, jj++) { fis. read (RELAY2-Port-Num);

287

fis. read (RELAY2-Pin-Num); fis. read (RELAY2-Port-Num); fis. Read (RELAY2-Pin-Num); RELAY2-interface [RELAY2-Port-Num][RELAY2-Pin-Num] Num*2+PUMP2-Pin-Num) } } void displayConnections () { } } Main () ( // draw all the Hardware Components String componetName; )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFHUHSRVLWRU\GDW´ while fis != Null) { Fis. read (ComponetName) LI &RPSRQHW1DPH ³5HVHW%XWWRQ { ResetButton RB = ResetButton (); RB. displaydevice (); } LI &RPSRQHW1DPH ³7HPSHUDWXUH6HQVRU´ { TemperatureSensor1 S1 = TemperatureSensor1 (); S1.displaydevice (); } LI &RPSRQHW1DPH ³7HPSHUDWXUH6HQVRU´ { TemperatureSensor2 S2 = TemperatureSensor2 (); S2.displaydevice (); } if (ComponetNDPH ³2SHUDWLRQDO$PSOLILHU´ { OperationalAmplifier1 OPT1 = OperationalAmplifier1(); OPT1.displaydevice (); }

288

= PUMP2-Port-

LI &RPSRQHW1DPH ³2SHUDWLRQDO$PSOLILHU´ { OperationalAmplifier2 OPT2 = OperationalAmplifier2 (); OPT2.displaydevice (); } if (ComponetNaPH ³$72'&RQYHUWHU´ { ATODConverter A2 = ATODConcerter (); A2.displaydevice (); } LI &RPSRQHW1DPH ³.H\ERDUG´ { Keyboard K2 = Keyboard (); k2.displaydevice (); } LI &RPSRQHW1DPH ³0LFURFRQWUROOHU´ { Microcontroller MC = Microcontroller (); MC.displaydevice (); } LI &RPSRQHW1DPH ³5HOD\´ { Relay1 MC = Relay1 (); MC.displaydevice (); } LI &RPSRQHW1DPH ³5HOD\´ { Relay2 MC = Relay2 (); MC.displaydevice (); } LI &RPSRQHW1DPH ³%X]]HU´ { Buzzer MC = Buzzer (); MC.displaydevice (); } LI &RPSRQHW1DPH ³+267´ { HOST MC = HOST (); MC.displaydevice (); } LI &RPSRQHW1DPH ³/&'´ { LCD MC = LCD (); MC.displaydevice (); }

289

LI &RPSRQHW1DPH ³3XPS´ { Pump1 MC = Pump1 (); MC.displaydevice (); } LI &RPSRQHW1DPH ³3XPS´ { Pump2 MC = Pump2 (); MC.displaydevice (); } } // draw Interconnections between the Devices Hardware Components )LOH,QSXW6WUHDPILV )LOH,QSXW6WUHDP ³'\GHYLFH,QWHU&RQQHFWLRQVGDW´ while (fis != null) { String fromdevice; String todevice; Fis.read (fromdevice); Fis.read (todevice); int fromPort; int toPort; int fromPin; int toPin; LI IURPGHYLFH {

³5HVHW´$1'WRGHYLFH

³0LFURFRQWUROOHU´

Reset-MC RMC = Reset-MC(); RMC.drawConnetcions } LI IURPGHYLFH {

³7HPSHUDWXUH6HQVRU´$1'WRGHYLFH

³2SHUDWLQDO$PSOLILHU´

Sensor1-OPT1 RMC = Sensor1-OPT1 (); RMC.drawConnetcions } LI IURPGHYLFH

³7HPSHUDWXUH6HQVRU´$1'WRGHYLFH

290

³2SHUDWLQDO$PSOLILHU´

{ Sensor2-OPT2 RMC = Sensor2-OPT2 (); RMC.drawConnetcions } LI IURPGHYLFH {

³2SHUDWLQDO$PSOLILHU´$1'WRGHYLFH

³$72'&RQYHUWHU´

OPT1-ATOD RMC = OPT1-ATOD (); RMC.drawConnetcions } LI IURPGHYLFH {

³2SHUDWLQDO$PSOLILHU´$1'WRGHYLFH

³$72'&RQYHUWHU´

OPT2-ATOD RMC = OPT2-ATOD (); RMC.drawConnetcions } LI IURPGHYLFH {

³.H\ERDUG´ $1'WRGHYLFH

³$72'&RQYHUWHU´

Keyboard-ATOD RMC = Keyboard-ATOD (); RMC.drawConnetcions } LI IURPGHYLFH {

³0LFURFRQWUROOHU´$1'WRGHYLFH

³%X]]HU´

MC-Buzzer RMC = MC-Buzzer (); RMC.drawConnetcions } LI IURPGHYLFH {

³0LFURFRQWUROOHU´$1'WRGHYLFH

³/&'´

MC-LCD RMC = MC-LCD (); RMC.drawConnetcions } LI IURPGHYLFH

³0LFURFRQWUROOHU´$1'WRGHYLFH

291

³+267´

{ MC-HOST RMC = MC-HOST (); RMC.drawConnetcions } LI IURPGHYLFH {

³0LFURFRQWUROOHU´$1'WRGHYLFH

³5HOD\´

MC-Relay1 RMC = MC-Relay1 (); RMC.drawConnetcions } LI IURPGHYLFH {

³0LFURFRQWUROOHU´$1'WRGHYLFH

³5HOD\´

MC-Relay2 RMC = MC-Relay2 (); RMC.drawConnetcions } LI IURPGHYLFH {

³5HOD\´$1'WRGHYLFH

³3XPS´

Relay1-Pump1 RMC = Relay1-Pump1(); RMC.drawConnetcions } LI IURPGHYLFH {

³5HOD\´$1'WRGHYLFH

Relay1-Pump2 RMC = Relay1-Pump2(); RMC.drawConnetcions } } }

292

³3XPS´

5.7 Code Generation framework for Embedded Software Code has to be generated for implementing the embedded software.

5.7.1 Requirements for framework to generate code related to Embedded Application 1. Identification and maintaining the standard code segments duly identifying the variables used as Global, instance, return, local or arguments to the functions. A convention to refer to the kind of variables and include elements must be designed and used. The code segments may also refer to some standard functions. 2. Identification and maintaining standard functions constructed out of the standard code segments and other functions. The variables to be used in the functions must be projected as Global, Local, instance, return or functional out of the definitions included in the code segments. 3. Mapping the standard functions as non-member functions and defining them as friend functions within the classes where the functions are required. 4. Mapping the member functions to the respective classes. While doing so, define the variables as instance or local. The global variables should be declared right in the beginning of the program file. 5. Recognize every software state in the state diagram and include the methods of the classes as the entry procedures. The methods should be executed whenever a transition is made to a software state due to occurrence of either an internal or external event. 6. Generate the code a. Include all the Global variables in the beginning of the program file. b. Include all the classes as defined in the class diagrams duly including instance variables, methods, local variables and the code. c. Develop a non-member main method by tracing all the logical paths in the state diagrams and include code that facilitates the execution of the logical paths. The higher level state diagram shall be used for scheduling the tasks that are repetitive in nature (Self loop states) and the lower level state diagrams are used for code generation within the main method.

293

Initiate the RTOS and include the RTOS functions that schedule the tasks and start the RTOS for commencement of the execution of the embedded application. d. Include all the non-member functions which are declared as friends within the classes.

5.7.2 Code Generation Framework for Embedded Software CRSE has advocated that the code is to be developed using the State Box specification. Procedures are to be executed when a system enters a state or leaves the state or while it is in the state. Entering a state happens when a state transition takes place. Since every state is a snapshot of an object of a class, the procedures are the functions that are encapsulated into the classes. Code generation, therefore, implies that the code related to the functions be developed either manually or through some automated means. Manual coding is always erroneous and it is important that the code is to be generated automatically so that high quality reliable code can be obtained. Code generation is one of the essential requirements of the Embedded Systems. Many authors have recommended for automatic code generation based on the design specification, but the code generation related to hardware design alone has been covered to certain extent and no recommendations have been available in the literature for generating the code related to embedded software. It has been recommended by [David E. Simon 1999] that generation of code for the embedded system in a very structured manner and using a particular architecture will lead to delivery of high quality Embedded Systems. One of the design principles of Embedded System is that the code be developed using a standard and structured methods based on the foundations of the Frameworks. It has been recognized that it is possible to determine standard code structures related to embedded systems. The standard code segments use global or local input and produce output again either local or Global. The standard code segments are in different files and can be included wherever necessary. The standard code segments can be stored in a library and the library can be grown when ever new code segments suiting to the embedded systems are identified and included into the library. Even Clean Room Software Engineering also advocated that standard control structures be used for delivering high quality code. The standard code functions can be identified by way of including the standard code structures and other standard code functions. Even a standard code structure can also

294

include a standard code function. The code structures and the functions are included in the sequence such that standard logic is implemented. The standard code functions are then mapped to the classes based on the expected responsibilities of the classes. The main control logic is implemented by way of taking the instances of the classes and calling for the functions through object references. The sequence in which the code contained in various classes gets executed based on the sequence flows that are built into the state Diagrams. Thus, the state diagrams and class diagrams that have been presented in the Chapter 4 for modeling the internal behavior of the embedded systems will be the foundations using which code generation Framework can be defined and used for generating the code related to any of the embedded systems. The code generation method proposed in this thesis is primarily based on the Library management which helps in reusing the library elements to construct code segments, code functions and functional modules. The framework for code generation involves several steps. A code function is a whole unit of execution generally involving one or more number of code segments. A set of code segments together with some other functions form a code function. The function units that are related to communicating with the hardware devices and the code functions units that are used as non-member functions are recognized and identified as the code functions. The code functions are either general purpose functions such as converting ASCII to HEX or specific member functions that processes and communicate with a peripheral device. The code functions will be defined with various types of variables based on the code segments included in them. Some more variables that are specific to the code functions are defined within the code functions. Every code segment will clearly recognize variables, their types and location where the variables must have been declared including the details of locations which include, Global, instance, local, functional arguments and return variables. This way of categorizing the variables will clearly help in mapping and constructing code functions and the class modules in which the code segments are placed. The code segments are pre identified and developed as a library over a period of time. The library is maintained and more number of code segments is added to the library as when needed, especially when a ES application is analyzed and designed. The code segments identified in respect of TMCNRS are placed in a Library of Code Segments. A code segment may include many other code segments or may even call code functions.

295

A repository of code segments can be maintained which will be used later for resolving and placing the variables in appropriate locations. The details of the repository constructed for locating and maintaining the standard code structures that help generating the code for TMCNRS are shown in the Table 5.3. The Framework is implemented through several steps of execution Step #1 Construct a Library of the code segments A code segments is a unit of execution that is required quite frequently. The code units that are related to communicating with the hardware devices and the code units that are used in non-member functions are recognized and identified as the code segments. Every code segment will clearly recognize variables, their types and location where the variables must have been declared including the details of locations which include, Global, instance, local, functional arguments and return variables. This way of categorizing the variables will clearly help in mapping and constructing code functions and the class in which the code segments are placed. The code segments are pre identified and developed as a library over a period of time. The library is maintained and more code segments are added to the library as when needed, especially when a ES application is analyzed and designed. The code segments identified in respect of TMCNRS are placed in a library Code Segments. Lib. A code segment may include many other code segments or may even call code functions. A Repository of code segments can be maintained which will be used later for resolving and placing the variables in appropriate locations. The details of the repository constructed for locating and maintaining the standard code structures that help generating the code for TMCNRS is shown in the Table 5.3. The contents of the Code Segments Library designed for TMCNRS are placed below: # LCD busy check segment (LCD-BUSY-CHK) # Global Variables #define set 01; #define reset 00 sbit rs=P3^5; sbit rw=P3^4; sbit en=P3^3; sbit busy=P2^7; # Local Variables int busy = 1; # Functional Variables # Code Begin

296

do { en=reset; rs=reset; rw = set; P2=0xFF; en = set; } while (busy==1); en = reset; rw = reset; # Code End

# LCD Command write Segment (LCD-COMMAND-WRITE) # Instance Variables # Local Variables # Global Variables # Functional Variables Int d; # includes busycheck () # Code Begin Rs = reset; P2=comm.; en =set; # includes delay (d); en =reset; # includes delay (d) # includes busycheck (); # Code End # LCD write Segment (LCD-DATA-WRITE) # Global Variables #define set 01 #define reset 00 sbit rs=P3^5; sbit rw=P3^4; sbit en=P3^3; sbit busy=P2^7;

297

# Local Variables # Functional Variables int dl=0; # Code Begin rs = set; p2 = dat; en = set; # includes delay (dl); en = reset; # includes busycheck (); # Code End # LCD N write Segment (LCD-NDATA-WRITE) #Global Variables #define set 01 #define reset 00 sbit rs=P3^5; sbit rw=P3^4; sbit en=P3^3; sbit busy=P2^7; # Local Variables int I; # Functional Variables Char Data [20]; # Code Begin for (i=0;i temperature2) { Diff = temperature1-temperature2; } else { diff = temperature2-temperature1; } PrcessBuzzer pB = processBuzzer (); ProcessLCD plcd = ProcessLCD (); if (diff > 2) { pB. buzzer =HIGH; plcd.command_write (0xD4); for (i=0;i