initial report on case study ... - newcastle...

Project IST-511599

RODIN “Rigorous Open Development Environment for Complex Systems”

RODIN Deliverable D8

Initial Report on Case Study Development

Editor: Elena Troubitsyna (Aabo Akademi University, Finland)

Public Document

31st August 2005

http://rodin.cs.ncl.ac.uk/

Contributors: Peter Amey (Praxis High Integrity Systems Ltd, UK), Joey Coleman (University of Newcastle upon Tyne, UK), Budi Arief (University of Newcastle upon Tyne, UK), Neil Evans (University of Southampton, UK), Alex Iliasov (University of Newcastle upon Tyne, UK), Ian Johnson (ATEC Engine Controls Ltd, UK), Maciej Koutny(University of Newcastle upon Tyne, UK) Linas Laibinis (Aabo Akademi University, Finland), Sari Leppänen (Nokia, Finland), Ian Oliver (Nokia, Finland), Alexander Romanovsky (University of Newcastle upon Tyne, UK), Colin Snook (University of Southampton, UK), Elena Troubitsyna (Aabo Akademi University, Finland),

CONTENTS 1 Introduction 4 2 Report on case study development for case study 1: Formal Approaches to Protocol

Engineering 6

3 Initial report on case study development for case study 2: Engine Failure Management System

17

4 Report on the case study: Formal Techniques in MDA Context 29 5 Case study 4: CDIS Air Traffic Control Display System 50 6 Initial report on case study development for case study 5: Ambient Campus – the

Lecture Scenario 63

3

SECTION 1. INTRODUCTION This document reports on the first year of the development of case studies in RODIN. The aim of case studies is to drive the development of RODIN methodology and supporting platform, validate it and evaluate its cost-effectiveness. While the deliverable D14 gives the precise assessment of the case study developments, in this document we focus mostly on describing the achieved results and outline the future plans.

In general, we believe that the work on the case studies is proceeding as planned. Within each case study we have identified challenging research topics to be addressed in RODIN methodology. While working on case studies we explored the corresponding domain specific models and problems. This allowed us to identify the additional requirements on supporting tool platform. Hence diversity of case studies has facilitated achieving versatility of the supporting platform.

The description of the achieved results and the outline of the future development for the case study 1 – Formal Approaches to Protocol Engineering – is presented in Section 2. This case study investigates the use of formal methods in the development of communicating systems. Its major goal is to explore an incorporation of formal methods into existing UML-based development cycle. The advances in creating a methodology for formalizing UML-based development and identifying the requirements for tool support are reported in this document.

Section 3 is devoted to the evaluation of the work done within case study 2 – Engine Failure Management System. The methods and tools developed in RODIN should potentially improve maintenance and re-use of the failure management systems. This task is tackled from two directions. The first direction investigates an accurate modelling of the domain to reduce the semantic gap between application requirements and systems design. The second direction explores how to promote reusability by developing configurable generic specifications. In this document we report on the current state of research on this topic and future plans.

In Section 4, the initial results of the work on the case study 4 – Formal Techniques within an MDA Context are presented. This case study is primarily aimed at constructing and verifying platforms or architectures rather than aiming at the applications themselves. The case study explores the problem related to the MDA development flow together with the role of verification/validation within that flow, as well as problems related to development methods used within Nokia. The section provides the background required to understand the scope of the case study, outlines the research directions and evaluates the obtained results. Section 5 analyses the initial results of the development of case study 4 – CDIS Air Traffic Control Display System. This case study aims at testing RODIN methods and tools on a complex, data-intensive and highly-distributed system. The system was successfully developed a decade ago but the development encountered a number of difficulties. The chapter presents the analysis of the challenges to be tackled, evaluates the initial results on addressing them and outlines further directions.

4

In Section 6 we present the overview of the development of case study 5 -- Ambient Campus. The aim of this case study is to investigate modelling, development and verification of fault tolerant mobile asynchronous systems. The work on the case study during the first year has addressed a number of fundamental theoretical issues, such as process algebraic and state-based approaches to modelling mobile systems, modelling fault tolerance, reasoning about correctness of ambient system etc. Moreover, this work has actively contributed to definition of the supporting platform and plug-ins. A brief evaluation of the achieved results and outline of plans are presented in this document. The case studies have naturally promoted a co-operation between academic and industrial partners and facilitated overall consolidation of the project. A number of joint research efforts have been initiated already during the first year and will be further expanded and strengthened during the next years.

5

�� "!$#�!�� %��&��(')� ��+*�� "!"#-,�./*��"'0��&1��2�(��3��45��+��6�(��+�"�&

� ��7��8�� 8��7

��9,:�:�;�<>=@?BADCFEG<IHJ?/;

KBLGM"N@OQPSRTOQU2VWLGM�X(Y/Z�[]\:O^`_�PSRbadcQce^fOQPSg>LGMih�VjO�kl^fOmVjOQgSOQRonqpGN@rspGMSMtûrspGN$[]rvh�VjO�rwpQxGMihuVvrWN@PtVvMPtcQcyRzrWgSPtVvrWOp)OQU5UJO^`_�PSR�_�M{V|LGOQ}Gh~UÒ^�}QMtxGMSRWOmce_�M>p@V�OQU�VjM�RWMSgSO_�_��QpGrzgSPtVjrzOp�hu�ehuVvM>_�h�P>pG}ceûOmVvOQgSOQRvhd�9klûOI��MSgtVF��M8h�g>ûr�cQVjrzOp�OQUT��O^`�5�z�l�|Zt�J��lKBLGM�ce^fOmVjOQgSOQR�M>pGN@rwpGMSM>ûrwpGN$Nm^fO�@c3rsp��O�GrzPLGPih�}QM>xGMSRzOmcyMS}�VWLGM��^fPS��_�MtV|LGOQ}1�dLGrWg>L�h��@cQcyO^`V9h5V|LGM�h�M>^`xGrWgSM8�9OûrzM>p@VjMS}�PtcQce^fOQPSg>L�VjOceûOmVvOQgSOQR MtpGN@rspGMSMtûrspGNy�Q��rwVWLGrsp�¡£¢2�d¤s�¥�¦M§PSrs_�PtV�ceûOxGrW}QrwpGN�h��@cQcyO^9V/�9rsp�VWLGM�UÒ^J_�OQU�UÒ^J_�P�RVjM�g>LQpGrW¨�GMih�P>pG}§VjOQOQR|h©�BUÒ^ xGP>^frWO�ªh«huVvPSN@Mih�OQU:V|LGr|h�PtcQce^fOQPSg>L:�

�2�QûrspGN�VWLGMdU`rs^�huVl�QM�P>^q�¦M¬LGP>xGMN@OmV®}QMSMtcyMt^q�QpG}QM>^©huVvP>pG}QrspGN�OQU®V|LGM¬�®�mûP(}QMtxGMSRWOmce_�M>p@Vl_�M{V|LGOQ}P>pG}�r�V`h�PtcQcyRWrzgSPtVjrzOp }QO_�PSrsp:�KBLGM¯gSOpGg>ûM{VjM�gSPih�M$huV|�G}m��hu�GN@N@MihuVvMS}3°@�±� O�GrWP8²VWLGM±KBLGrwû}³ M>pGM>ûP{VjrWOp3k�P>^9V|pGM>^�h�LGrwc�klûOI��MSgtVD�`´ ³ k:k:�DcyOGh©rwVjrzOpGrspGN�h©M>^JxGrzgSMi² UJP�gSrWRzrwVjP{VjMS}3huVW�G}m�QrwpGN�V|LGM��®�^fP}QM>xGMSRzOmce_�M>p@V�ceûOQg�MihIh-P>pG}�h©M>^JxGMS} Pih+P�VvMihuVW°GM>pGg>L�UJO^/Mt_�M>^fN@rspGNµUÒ^J_�P�Ry_�MtVWLGOQ}QOQRWOQN¶�µP>pG}VjOQOQR|ht�

��M(LGP>xGM¦hfVjP>^9VjMS}µVjO�UÒ^J_�PSRWr|h�M(VWLGMd��^fP§}QM>xGM�RWOmce_�Mtp@V�ce^fOQgSMihIhbrsp V|LGM2·]¸�M{V|LGOQ}±�z�l�¹´@��mKqLGM(·¸�MtVWLGOQ}ºrvh�P>p�PtcQce^fOQPSg>L�VvO�rwpG}�ªhuV|^frWPSR+}QM>xGMSRzOmce_�M>p@V]OQU�LGrWN¶LGRw�»}QMtcyM>pG}QPt°GRWM�h�OQUjVW�¦P>^fMi²h��@cQcyO^9VjrspGN¼UÒ^J_�P�R hu�GhfVjM>_ }QM>xGM�RWOmce_�Mtp@V�°@��V|LGM½huVvMtce�¦r|h�M�ûMSU`rspGM>_�M>p@V�_�M{V|LGOQ}��T��M�LGP>xGM}QM>xGMSRzOmcyMS}�V|LGM�Nm�GrW}QM�RWrspGM8h�UÒ^¦V|^fP>pªh�RWP{VjrspGN�VWLGM��^fP�¾§¸��B�+_�OQ}QM�Rvh�rsp@VvO5·0hucyMSgSrzUJrzgSPtVjrzOpªht�¸�O^fMSOxGM>^©²��M$LGP>xGM�PihIh©OQgSrWPtVvMS}�V|LGM"�®�mûP$}QM>xGMSRWOmce_�M>p@V£ceLGP8h�Mih��rwVWL�V|LGM"gSO^`ûMihfcyOpG}QrspGN�·}QM>xGMSRzOmce_�M>p@V§huVjMtc�h¦[�·�ûMSU`rspGM>_�M>p@V`h{��KBLGr|h�g>ûMSP{VjMih�VWLGM±°GPih�r|h�UJO^§xGM>ûrzUj�@rspGN�gSO^`ûMSg{V|pGMihIh OQU_�P�rsp }QM>xGMSRzOmce_�M>p@VyceLGPih�Mih�OQU®�®�mûP�

¤vp�PS}Q}Qr�VjrzOpª²��M¿LGP>xGMd}QM>xGMSRzOmcyMS}¥P(·ÀhucyMSgSrzUJrzgSPtVjrzOp cyP{VWVjMt^Jp�UÒ^�P2gSO_�_��QpGrWg�PtVjrwpGN�h©M>^JxGrzgSMgSO_ cyOpGM>p@V`²e�dLGrWgtL�gSP>p�°GM2�QpG}QM>^©hfVjOQOQ}�PihoP��>°Q�GrzRW}QrwpGN °GRWOQgt�G��OQU/gSO_�_��QpGrWgSP{VjrspGN�hu�ehuVjMt_�hbrsp�®�mûP�oKBLGM3cyP{VWVjMt^Jp~gSP>p�°GM3ûMSg>�Q^�h�rsxGM�Rw�½�ªh�MS}5VvO¼hucyMSgSrzUj��h�M>^`xGrWgSM�gSO_�cyOpGMtp@V`h�Op�}QrWUJU`M>ûMtp@VRWP{�QM>^�h§OQU£Pt°ªhuV|^fPSgtVjrzOp:�:��M�LGP>xGM�P�Rvh�O�rz}QM>p@VjrzUJrWM�}¯P>pG}�UJO^`_�PSRzrvh�MS}�V|LGM�g�O_�_��QpGrzgSPtVvrWOpGPSR�P>pG}U9�QpGg{VjrWOpGP�RªPihucyM�gtV`h�OQUBh��Gg>L gSO_�_��QpGrzgSPtVjrwpGN¦gSO_ cyOpGM>p@V`ht�

\:rspGP�RWRw�e²:��M LGP>xGM�huVjPt^`VjM�}�VjO�VvPSg>�GRzM�UJPt�GRwV�VjOQRWMtûP>pGgSM P>pG}�cyP>ûPSRzRWMSRzrvh�_»r|hIh��GMihTV|LGPtVFP>^fM�rwpQLGM>ûMtp@VUJO^(VvMSRWMSg�O_�_��QpGrzgSPtVvrWOp�hu�GhfVjM>_�ht� ��M�P>^fM�N@OQrspGN$VjO3U9�Q^9V|LGM>^drwpQxGMihuVvrWN@PtVvM�V|LGMih�M�r|hIh��GMih¦}�QûrwpGNV|LGM(h�MSgSOpG}§�@MSP>^BOQU:V|LGMT¡¬¢(�§¤s�ÁceûOI��MSgtVu�

��w ��l'�ÂyÃi?/=�!�H�=@ÄyEe<ÅHJ?q;FÆµHu;Ç��ÂBÆiÄ"��<{CFA�È�!�ÄÉ�ÄGÊJ?/ËbÌ�Äª;�<

Í¼Î>ÏJÐ�ÑQÒ�Ñ@ÓWÑQÔ@Õ|ÖS×@Ó�Õ|Ø�Ø�Ù�ÎSØTÚ�ÛSÑ@Ù�Ô@ÐlÏFÙ:Ü�ÚGÝ±ÏJÐ®ÎdÖS×QØIÎdØ�ÏJÙ®ÒeÝlÞGKqLGMdgSPih©M¦huVW�G}m��LGPihFûPSr|h�MS}�h©M>xGM>ûP�Rrsp@VvM>ûM8huVjrwpGN�_�MtVWLGOQ}QOQRWOQN@rzgSPSR�r|hIh��GMiht�¶KBLGM£_�P�rsp�N@OQPSR�OQU:V|LGM(gSPih©MdhuV|�G}m�µrvhqVvOµPSg>LGrWMtxGM¬P>�@VjO_�PtVjrzgV|^fP>pªh�RzPtVjrzOpÇOQUßV|LGM»¾§¸��B�G�v°GPih�MS}¯}QMtxGMSRWOmce_�M>p@V�OQU�gSO_�_��QpGrWgSPtVvrspGNàhf�GhuVvM>_�h�rsp@VjO6VWLGM

6

áSâã`ãuäiåuæyâçGèQéwçGê�åfæyäSáSéWë`éWáSì{íjéWâç�ì>çGè�ãuäSë`ésçGä>î�ä>ç@íbæeãuâQá�äiåIå¦ésç�í|ïGä�ðòñ�ätí|ïGâQè�ó®ôBïGâ�ìSátïGéWä>õGä�í|ïGé|åIö÷ ä�çGäSäSè±ívâ�èQä>õGäSøWâmæ�ì�ê@ä>çGä>ãfìSø/î�ätí|ïGâQèQâQøzâQê¶ù�å�ú@æQæyâã`ívésçGê±ì>ú@íjâî�ìtíjézá�í|ãfì>çªå�øzìtíjézâç¯âQëbû�ñ�ü ýGþÿ ìiå�ä�è�î�âQèQäSøvå£éwç@íjâ�í|ïGä¦ðÁåuæyäSáSézëJézáSìtíjézâç±øWì>çGêmúGì�ê@äó��(çGá�ä§í|ïGä�î�ä{í|ïGâQèQâQøWâQêiù�évå£èQätõGäSøWâmæyäSèGö ÷ ä÷ éWøWø�áSâQâmæyä>ãfìtíjä ÷ é�í|ï$íWïGä û§ýQð��zýló��oívâQâQø�èQätõGäSøWâmæyä>ã�å¬ívâ�æeãuâõGézèQä�ì>ú@ívâî�ìtívéWá¦íjâQâQø�å�ú@æQæyâã`íFë`âãå�úGá>ï¦íWãuì>çªå©øWìtívéWâç:ó

ô/äSøWä�áSâî�î�úQçGéWáSìtívéWâç�åuùGåfíjä>î�å�âmæyätãuìtívä~éwç�õGâQøzìtíjéwõGäiöµä>ãJãfâã"æeãuâçGä¼ä>çQõGésãfâçQî�ä>ç@ífó�ôBïGä�î�âGåfííWù¶æyéWá�ìSø¦ëJìtúGøwí`å$ìtãuä�øWâGåfí âã�áSâã`ãJú@æQíväSè�áSâî�î�úQçGéWáSì{íjéWâç�î�äiåIå�ì�ê@äiå ÿ ätí ÷ ä�ä>ç~èQévåuívì>ç@í¦çGä{í ÷ âã�äSøzä>î�ä>ç@í9åtó:ôBïGä>ãuä�ëJâãuä8ö ëJì>úGø�íFíjâQøzä>ãuìtçGáSä�å�ïGâúGøzè ÿ ä�ì>ç3ésç@íWãuéwçªå�éWá�ëJäSìtíWúQãuä�âQëbíväSøWäSá�âî�î�úQçGézáSìtívéWâçåuùeåuíjätî�åtó�§ä>çGáSä íWïGä ëJìtúGøwíòívâQøWä>ãfì>çGáSä6î�äSá>ïGì>çGé|å�î�å�å�ïGâúGøWè ÿ ä éwç@íjäSê¶ãuìtíväSè ésç@ívâ ÿ âmí|ïåuæyäSá�éWëJézáSìtívéWâç ì>çGèµèQä>õGä�øWâmæeî�ätç@íªæeãuâQá�äiåIå�âQëBå�úGá>ï�åuùeåuíjätî�åtó

ô/äSøWä�áSâî�î�úQçGéWáSìtívéWâç�åuùeåuíjä>î�ådæeãuâõGéWèQä�áSätã`íjì�ésç�å�ä>ãJõGézáSäiå¦ëJâã¬íWïGä�ä �Qíjä>ã`çGìSøFúªå�ä>ã�åtó�ûµå�úGìSøzøwù"íWïGäå�ä>ã`õGéWáSä¿ä �yäSá>ú@íjézâç�évå½èQé|åuí|ãfé ÿ ú@íväSè1âõGä>ã�èQé|åuíjéwçGátí"çGä{í ÷ âã��äSøzä>î�ä>ç@í9å ÷ ïGéWá>ïòæeãfâõGéWèQä�í|ïGäSéwãå�ä>ã`õGéWáSä8å�ìiå2æyì>ã`í9å�âQëDí|ïGä�ãfä��úGésãfäSè�å�ä>ã`õGéWáSä�ä �yäSátú@íjéWâç:ó��2ëjívä>ç"í|ïGä8å�ä�å�ä>ã`õGéWáSä8å§ì>ãuä�ä �yäSá>ú@íjä�è�ésçæyì>ãfìSøWøzäSø`ó��ä å�ïGâúGøzè¯ívì �Gä�æyì>ãuì�øWøWä�øWévåuî ésç@íjâ ìSáSá�âúQç@í ÷ ïGézøWäºî�âQèQäSøzøWéwçGê âã1õGätãuéWëvùQéwçGêíjä�øWäSáSâî�î�úQçGézáSìtíjézâç�åuùeåuíjä>î�åtó

ôBïGä"ü®ùmãuì�èQä>õGäSøzâmæeî�ä>ç@í2évå�á>úQã`ãuä>ç@ívøwù�õGì�øWéWèQì{íjäSè ÿ ù�úªå©ésçGê�î�âQèQäSø|þ ÿ ìiå�äSè�íväiåuíjéwçGê�âQë2æeãfâQêmãuìtîáSâQèQä�âã�éwç@íjä>ã`î�äSèQézìtíjä]û§ñ�üBýßî�âQèQäSøvåtó(ð«ù~í|ãfì>çªå�øWì{íjésçGê¼í|ïGäiå�ä5û�ñ�ü ýÁî�âQèQäSø|å�ésç@ívâí|ïGä]ðåuæyäSá�éWëJézáSìtívéWâçªåIö ÷ ä ÷ âúGøWèºátãuäSìtíväµìSèQèQéwívéWâçGìSø�î�âãuä§æeãfäSáSé|å�ä åuùeåuíjä>î�î�âQèQäSø|åoí|ïGìtí�á�ì>ç ÿ ä�úªå�äSèíjâµë`ìSáSézøWéwívìtíjä+íjäiåuílê@ä>çGä>ãfìtíjézâç:ó

�� !��"!��$#%!�&��')(�'*��+��&+�,��-��!�'*�-'.�,(��$/ ó0��ä ÿ äSøzéWä>õGä�í|ïGì{íBí|ïGä�î�ätí|ïGâQèQâQøzâQê@éWáSì�øãuä8å�úGøwí9å§ìSá>ïGézä>õGäSè�èúQãuéwçGê�í|ïGä�ëJésã�åuíFù@äSì>ã¬âQëoíWïGä æeãuâ*1�äSátíoä8åuíjì ÿ øzévå�ï3ì�å�âQøWézè ÿ ìiå�évådëJâã£á>ãuäSì{íjésçGê±ìî�ä{í|ïGâQèQâQøWâQêiù�ëJâã�ëJâã`î�ìSø:èQä>õGäSøzâmæeî�ä>ç@í âQë/áSâî�î�úQçGéWá�ìtíjéwçGê�åuùeåuívä>î�åtó2��ä¬ïGì>õGä2ìiåIå�âQá�éWìtíväSèµíWïGäåuívìSê@äiå)âQë�ü®ùmãuì6èQä>õGäSøzâmæeî�ä>ç@í ÷ é�í|ï í|ïGä áSâãJãfäiåuæyâçGèQésçGêàð èQä>õGä�øWâmæeî�ätç@í�åfíjätæ�å43 ðãuä�ëJésçGätî�ä>ç@í9åtó

��ä£ïGì>õGä(á>ãfäSìtíväSè�ì¬ð�åuæyäSá�éWëJézáSìtívéWâçµæyìtíWívä>ãJç�ë`âã/ì(áSâî�î�úQçGéWáSì{íjésçGê å©ä>ãJõGézáSä(áSâî�æyâçGätç@í ÷ ïGézá>ïévå�ì65 ÿ úGézøWèQésçGê ÿ øWâQá �75�âQë�á�âî�î�úQçGézáSìtívésçGê�åfùGåuívä>î�å�ésç�ü�ùãfìóbôBïGä�æyìtízíjä>ã`ç¼áSì>ç ÿ ä3úªå�äSè+íjâåuæyäSá�éWëjù�áSâî�î�úQçGéWá�ìtíjéwçGê¼å�ä>ã`õGéWáSä�á�âî�æyâçGä>ç@í9å�ìtí¦èQéWë`ëJä>ãfä>ç@íµøzìtù@ä>ã©å�âQë�ì ÿ åfí|ãuì�átíjézâçªöTäó êªó öbíWïGäáSâî æyâçGä>ç@í`å2æeãfâõGéWèQésçGê3å©ésçGê@øzä�ä �Qíjä>ã`çGìSøoå�ä>ã`õGéWáSä8å�âã£í|ïGä�áSâî æyâçGä>ç@í`å�âãfá>ïGäiåuíWãuìtívésçGêàå©ä>ãJõGézáSää �yäSá>ú@ívéWâç ÿ ù§ãuäSø�ùQéwçGê¦âç âmí|ïGätã"8`øzâ ÷ ätãqøWì{ùQä>ã9/å�ätãJõGéWá�ä¬áSâî�æyâçGätç@í`åtó

��ä§ïGì>õGä�éWèQä>ç@ívéWëJézäSè�áSâî�î�úQçGéWá�ìtíjézâçGìSø ì>çGè�ëjúQçGátíjézâçGìSø�æyì>ã`í9åDâQë�áSâî�î�úQçGéWáSìtívésçGê�áSâî�æyâçGä>ç@í9åì>çGè ëJâã`î�ìSøzévå�äSè í|ïGätî ésç ðdó ðDâmí|ï áSâî�î�úQçGéWáSì{íjéWâçGì�ø�ì>çGè ëjúQçGátíjézâçGìSø æyì>ã9í`å âQë ìáSâî�î�úQçGéWá�ìtíjéwçGê$áSâî æyâçGä>ç@í`å2ì>ãuä�åuæyäSáSézëJéWä�è"ésç�åuúGá>ï�ì ÷ ìtù�í|ïGì{í�íWïGätù±áSì>ç ÿ ä�éwçªåuíjì>ç@ívéWìtíväSè ÿ ùèQéWë`ëJä>ãfä>ç@í�áSâçGá>ãuä{íjäòá�âî�î�úQçGézáSìtívéWâç æeãuâmívâQáSâQøvå�âã½áSìSøWátúGøWìtívéWâçGìSø�ìSøzê@âãué�í|ïQî�å�èúQãuéwçGê1íWïGäèQä>õGäSøzâmæeî�ä>ç@í:8jãfäSëJéwçGä>î�ä>ç@í 9�æeãfâQáSäiåIåtó

��ä�ïGì>õGä½ì�øvå�âèQä>õGäSøWâmæyä�è~ãuä�ëJésçGätî�ä>ç@í�æyìtízíjä>ã`çªå ÷ ïGéWá>ïÁëJâã`î�ìSøzévå�ä�í|ïGä+èQäSáSâî æyâGå�éwívéWâç¿ì>çGèèQévåfí|ãué ÿ ú@íjézâçòåuíjätæ�å3ésçÁí|ïGä5ü®ùmãuì8þjð�èQä>õGäSøWâmæeî�ä>ç@íuó¬ôqïGä�æyìtíWívä>ãJçªå�áSì>ç ÿ ä½ésçªåuívì>ç@íjézìtíjä�èÁëJâã$ìåuæyäSá�éWëJézá�ë9úQçGá{íjéWâçGì�ø�âã�çGä{í ÷ âã�~ì>ãfá>ïGéwíväSátí|úQãfäóoôBïGä3úªå�ä�âQëµíWïGä3ãfäSëJéwçGä>î�ä>ç@ídæyìtízíjä>ã`çªå ÷ âúGøWèìSøzøWâ ÷ úªå�íjâòìtú@íjâî�ì{íjä�õGä>ãuézëJéWá�ìtíjézâç1âQë$í|ïGä¼ü®ùmãuì~èQä>õGäSøWâmæeî�ä>ç@í�æeãuâQáSä8åIåtó¦ôBïGé|å ÷ âúGøWè ÿ ä

7

;�< =7>@? A7?�B�C�DE; F�GIHKJL;MGI>�<6N$OPH�H�QRH�QSOP?�QT>VU7? JR? U�GTWXC7?MG�YZ?[? U�G =7?\<�HKOTOP?]WPN�HKU7B�>Û7_a`bJRH�B�?�cIWXC�DJL?[; UdWeH�Q:G�=7?f; A7;�>@c�; C7c@?gGhH�H�ciWjF�N�N�HKOTG,kl ?m; O,?m< F�OTOP? U�GIc^DnB�? A7?�c�H2N�>Û7_o` JLH�B�?�c WpH�Q4G�=7?mQ;MF7c^GqGhH�c�?MOP; U7<�?rJL?�<M=7; U7>IWjJsWbQTHKO<�HKJtJuF�U7>�<[;MGh>Û7_vWPD$WPGh?MJXWE;MU7Bw>VU�GI?�_2OP;xGh>VU7_yG =7? J >Û�GhH4G�=7?zW,N�?�<�>�QT>�<�;xGh>�HKUw; U7B�O,?�Q>Û7? JL?MU�GN�;MG@Gh? OTUdW{H�Q|<�HKJtJuF�U7>@<�;MGh>Û7_R<�HKJSN�HKU7? U�GTWMk$}~=7?ZQT; F7c^G�GhH�c@? OP; U7<[?�JL?�<M=7; U7>IWjJsW�Y�>�c�c�;�c�c@HKY�FdW�GhHJLH�B�?[c�W�>VJtN�c@?�O,?�<�HKA7? O�D\N$OPH�<�?[BKF�OP?]WL>VU�G =7?�<�;]W.?�WuY�=7? U�;�W.? OA7>@<�?�<�HKJtN�HKU7?MU�G�Q;�>@c�?�B�HKOS;<�HKJtJuF�U7>�<[;MGh>@HKULJL?]W*W�;�_�?�=7;]W�C7?�? UXc�H7W,GPk��\HKO,?ZB�?MGh;[>�c�?[BLQ; F7c�G�GIH�c�? O,; U7<�?�JR?�< =7; U7> WjJXW�YZ>@c�c%C7?>VU�GI?�_2O,;MGh?�B�;MG0W.HKJL?Ec�;xGh? O�B�? A7?�c@H2N$JL? U�G0WPGI?MNzY�=7? U�G =7?�B�?MGI;�>�c W\H�Q�FdW�?�B�<[HKJuJuF�U7>@<�;MGI>�HKUN$OPH2GIH�<�H�cIW�C7?�<�HKJL?�; A7;�>�c@; C7c�?2kl ?�; O,?�;�cIW.Hs>ÛRG =7?�N$O,H�<�?]W*W{H�QeQHKOTJuF7c�;xGh>VU7_-G =7?�N$O,?�<�>IW�?Z<�HKOO,?]WPN�HKU7B�? U7<[>�?]W�C7?xG Y�?�? URG =7?��DKO,;� ��~�6JRH�B�?�cIW-; U7B+G =7?�<�HKOO,?]WPN�HKU7B�>Û7_�`�WPN�?[<�>�QT>�<�;MGI>�HKUdWMk�}~=7?]W.?X<�HKOO,?]WPN�HKU7B�? U7<�>@?]W�YZ>@c�c�C7?FdW.?�B�QTHKO�; F�GIHKJL;MGI>�<gG�OP; UdW�c�;MGI>�HKUSH�Q:G�=7?��D2OP; � ��~�ZJRH�B�?�cIW�>VU�GhHZ`�kl ?Z=7; A7?tWPGh;MOTGh?[BLGIH�>Û�A7?]WPGh>@_�;MGI?ZN�;MOP;�c@c�?�c~?M�d?[< F�Gh>@HKU�H�Q|<�HKJuJtF�U7>�<�;MGI>VU7_XW.?MOA7>�<[?�<�HKJtN�HKU7? U�G�WMkl ?n<�;MU JLH�B�?�cyN�; OP;�c@c�?�c�? ��?�< F�GI>�HKU H�QbB�>�QTQ? O,? U�G�W.? OA7>@<�?]Wr;�cVO,?�;�B2D ;MG�G =7?�W�? OA7>@<�?B�?�<�HKJSN�H7W.>^GI>�HKU0N$=7;]W.?2k��HKOP?�HKA7? Oj��YZ?L; O,?L_�H�>VU7_�GIH A7? OP>@QhD�N�H7W¡W.>VC7c@?RB�>IWPG�OP>^C�F�Gh>�HKU+H�Q�N�; OP;[c�c�?[cC7? =7; A7>@HKF�O�HKA7? O�G =7?f_K>VA7? U�U7?MG�YZHKOT¢S; OP<M=7>^Gh?[<MG F�O,?f;MGdG�=7?�W.? OTA7>�<�?�B�>IWPG�OP>VC�F�GI>�HKUZN$=7;]W�?Kk£¥¤X¦�§�¨ ©�ª�«|©¬�Z¨�§�®*Z®�©,¯�°$±0ª�² ©,¬��¦:³ §K©«Pª�´[¤b°:*µ%[³�ª�¦�¤�[²%©P¶L· W�;�O,?]WjF7c^G~H�Q~G =7>IW�<�;]W.?ZWPG F7B2D$�Y�?v; OP?v_�H�>Û7_pGhHrB�? A7?�c@H2N¸;v<�H�c�c@?�<MGh>@HKU¹H�QEN�;MG�GI? OUdWºQTHKO�WPN�?�<[>�QhD�>VU7_»;MU7B»B�? A7?�c�H2N�>Û7_<�HKJtJuF�U7>�<[;MGh>Û7_-WPD$WPGh? JsWMk£¥¤X¦�§�¨ ©¼ª�«½©¬�q¨[§�®*�®.©,¯�°$±pª�²b©,¬�¾¦:³�¯�¿�ÀÁ@²Â°:*µ%[³�ª�¦�¤�[²%©P¶ }~=7?�<�;]W.?�WPG�F7B2DÃW.?MG�W¼G�=7?OP?[ÄKF7>VOP?MJL? U�G�W�QHKOuG�=7?\B�? A7?�c�H2N$JR? U�GSH�QSG�=7?6JLH�B�?�c�ÅhC7;]W�?�B�Gh?]WPGI>VU7_¼N�c^F7_�ÅT>ÛÆHKU�G�=7?6C7;]W.>IWXH�Q? ��N�? O,>�? U7<�?s;�<[< F�JuF7c@;MGh?�B+;MG�G�=7?SÇSHK¢7>�;RO,?]W.?�; O,< =6<�? U�Gh?MO*k�}~=7?uOP?�ÄKF7>ÔP? JR? U�GTW�QTHKO�G =7> W�N�cVF7_�Å�>VU; O,?¼B�?]W�< OP>^C7?�BÆ>ÛÉÈsÊ�Ê]k l ?�N�c�; UEGhHÆ>Û�Gh?�_ËOP;MGI?¼HKF�O�?�QTQHKOTG�W Y�>^G�=ÌG�=7? � ��`»B�? A7?�c@H2N�? O�W0HKU; F�GIHKJL;MGI>�<sG�OP; UdW�c�;MGI>�HKU½H�QfG =7?s��D2OP; � ��JLH�B�?[cIW�>VU�GhH+`�k~}~=7? OP?[QHKOP?��~G =7?X<�;]W�? WPG�F7B2D�JL;MD=7; A7?f>^JtN�;�<xG:HKUZG =7?�B�? A7?�c�H2N$JR? U�G:H�Q%G =7? � ��`�N�cVF7_�Å�>VU:k

ÍeÎ^Ï�ÎiÐ+ÑdÒ|ÓÔKÕeÔ7Ö¼×�Ô7ØKÙ|Ú�Û¥Ø

}~=7?6QT>VO�W,G�D�?�; OtH�Q�G =7?�ÜfÝ)È�Þ@Ç¹N$O,H*ß*?�<xGZHKF�O-Y�HKO¢¼=7;]WsQTH�< FdW.?�B¼HKU¼G�=�OP?�?0JL;ß¡HKO�Gh;]Wj¢dWsà,W�?�?á OPH*ß¡?�<MG%È�?]W.<MOP>^N�GI>�HKUSH�Q l HKO¢�â@�%k ÊMãä*å

æ�çË¶�çË¶�ç È�?�Q>Û7?gG =7?f<[;]W.?�WPG�F7B2D7�K?MA7;�cVF7;MGI>�HKUZN�c@; Ud�ËJL?�;�WjF�OP? JR? U�GTW�; U7B�;]W*W.?�W*WjJL?MU�G:< O,>^Gh?MOP>�;2kæ�çË¶�çË¶éè Ü�?MA7>�? Y�G =7?Lê[��D2OP;[êuJL?MG�=7H�B+;MU7B+>@B�? U�Gh>@QhDXG =7?RB�?MA7?�c�H2N$JR? U�G{WPGI?MNiW*��Y�=7>�< =6WP=7HKF7c�B

C7?fGh;[< ¢7c�?�B-C�DSÜfÝ)È�Þ@Çsk · W*W.>@_2UtG�=7?�W.?MGTW�H�Q�JR?MG =7H�B7W�; U7BZGh?�<M=�U7>�ÄKF7?]W�GhH�C7?�;MN�N�c�>@?�B;xGdG =7?�W.?�WPGI?MNiWMk

æ�çË¶�çË¶ìë ÞIU�A7?]W,Gh>�_K;MGh?ZG =7?�FdW.?-H�Q|OP?�QT>VU7? JR? U�Ge; U7BLJLH�B�?�c�<M=7?�< ¢7>VU7_uGIHsA7? O,>�QIDXB�?�<�HKJSN�H7W.>^GI>�HKU;MU7BÆ<�HKJSN�H7W.>^GI>�HKUqW,Gh?MNiWMkgÞIU�A7?]WPGI>�_�;MGI?6G =7?½<�HKJuC7>Û7;MGh>@HKUÉH�QuJRH�B�?�c�< =7?�<M¢7>VU7_�; U7BO,?�Q>Û7? JL?MU�G�GI?�< =�U7>@ÄKF7?]W�>Û0<�HKU�GI? ��G|H�Q � ��; U7Bs`�k�ÞIU�A7?]WPGI>�_�;xGh?�G =7?ZFdW.?-H�Q|JLH�B�?[c<M=7?�< ¢7>VU7_oGIH�H�cIWÂ>VU <�HKJuC7>Û7;MGh>@HKU Y�>^G�= � �� GhH ` GIH�H�cTkEÞIU�A7?]WPGh>@_�;MGI?mG�=7?;xN�N�c�>�<[; C7>�c@>^G�DZH�Q�QTHKOJR;�c7O,?�;]W.HKU7>Û7_Z; C7HKF�G:QT; F7c^G�GhH�c@? OP; U7<[?f>VUZG�=7>IWe;MN�N�c@>�<�;xGh>�HKUS;MOP?�;Kk

8

í~î7ï{ðLñ[òVó�ôPï�õjö7÷^ø�õeñ�ù î7ò@ï ú7ï�û�ûKö�ôPò^ó7ü�ø î7ï�ýòVôjõPødþ�ï�ñ ô~ñ ôPï�ø î7ïfýTÿ�÷�÷�ÿ��òVó7ü�� ïgî7ñ ú7ï$ôPï��ñ ôPï�û�ø�î7ïgø ô,ñ�ù�ï�ñ �7÷�ï{ô,ï��Kö7òVô,ï ðLï ó�ø%û�ÿ�ù ö�ðLïMó�ø�� ~ýTÿKô�ø�î7òIõeù�ñ�õ.ï�õPø�ö7û2þ �� ï�î7ñ ú7ïZû�ï ú7ï�÷@ÿ��ï�ûtø î7ï�ü2ö7ò�û�ï�÷@òVó7ï]õgýÿKôeø�ôPñ ódõ�÷�ñMøIòVó7üSø�î7ï��þ2ôPñ��RðRÿ�û�ï�÷Iõ{ò^ó�øhÿ��

õ �ï�ù�ò�ýTò�ù�ñxøhò�ÿKódõ �!"�� ïºî7ñMú7ïyñ]õ*õ.ÿ�ù�ò@ñMøhï[ûwø�î7ïyû�ï�ù�ÿKð#�ÿ7õ.ò^øIò�ÿKópñ ó7û�û�òIõPø�ôPò$��ö�øhò�ÿKóÂõPøIï iõÆÿ�ý�ø�î7ï%��þKô,ñ

û�ïMú7ï�÷�ÿ�$ðRï ó�ø"$ô,ÿ�ù�ï]õ*õ&��ò^ø�îZø î7ïfù[ÿKôôPï�õ'�ÿKó7û�òVó7ü��\ô,ï�ýò^ó7ï ðLï ó�ø�õPøhï�iõ �()�� ï î7ñ ú7ï û�ï ú7ï�÷@ÿ��ï�û ø î7ï � õ �ï�ù�ò�ýTò�ù�ñxøhò�ÿKó ñMó7û ôPï�ýTòVó7ï ðRï ó�ø*�ñMø@øhï ôTódõ ýTÿKô

ù[ÿKðuðuö�ó7ò@ù�ñMøIòVó7ü-õPþ$õPøIï ðXõ"ðRÿ�û�ï�÷�÷@ï�û�òVó+��þKô,ñ �, �� ï î7ñMú7ï õPøhñ ô�øhï�û¸øIÿ òVó�ú7ï]õPøIò�ü�ñxøhïÂýTÿKôðLñ[÷EðLÿ�û�ï[÷�÷�ò^ó7ümÿ�ýºýTñ ö7÷^øÌøhÿ�÷@ï ôPñ ó7ù[ïÂñ ó7û

�ñMôPñ�÷@÷�ï�÷@òIõjðzñ]õ'�ï�ùMø�õeÿ�ý:øIï�÷�ï[ù�ÿKðuðtö�ó7ò�ù�ñMøIò�ÿKóuõPþ$õPøIï ðXõ �

� ï-$ôPï]õ�ï ó�ø�ø î7ïRðLÿKô,ïsû�ïMøhñ�ò@÷�ï�û ô,ï]õjö7÷^ø�õ.��þ ödõ.ò^ó7ü�ø î7ïLù�ñ�õ.ïXõPø ö7û2þ+õjö7ü�ü�ï�õPøhï�û/��þ10tÿ�27ò@ñ+36ø�î7ï!547686 �ÿ7õ.ò^øIò�ÿKó7ò^ó7ü�õ,þ7õPøIï ð �� :9�; � �=< � ��> ó½ø î7ï�ýTòVô�õ,ø7�ñ ôTø?��ï0û�ï ðLÿKódõ,ø ôPñxøhï�ø î7ï/��þKô,ñ@��A�CB�7ñ]õ.ï[ûLû�ï ú7ï�÷�ÿ�$ðRï ó�ø"ÿ�ý�ø î7ï-õ,þ7õPøIï ð � í~î7ï ó1��ï�õPî7ÿ��qî7ÿ��D��ï�ù�ñMósýÿKôTðLñ�÷@òIõ.ï�ñ ó7ûtú7ñ�÷@ò�û�ñMøIï�ø î7ò õ��þ2ôPñfû�ïMú7ï�÷�ÿ�$ðRï ó�ø��þ�ödõ.òVó7ü�ø î7ïE�F�\ïMø�î7ÿ�û �

GIHKJIHMLONQP)R�STSVU8W�JIXTYZY\[8]5^`_�ab_c]VUd_MU8eT^ P)^fa'gih

��þ2ôPñj�� =k ��òIõ�ñ�ðRÿ�û�ï�÷cB�ûKôPòVú7ïMóLñ ó7ûtù�ÿKðj�ÿKó7ï ó�ølBl�7ñ]õ�ï�ûtû�ï�õ.ò�ü2óSðLïxø î7ÿ�ûSýÿKô~ø î7ï�û�ï ú7ï[÷�ÿ�$ðLïMó�ø�ÿ�ýù�ÿKðtðuö�ó7ò�ù[ñMøhò^ó7üºõ,þ7õPøIï ðXõ�ñ ó7û�ù�ÿKðtðuö�ó7ò@ù�ñMøhò@ÿKóm$ôPÿ2øhÿ�ù[ÿ�÷Iõ �?> øLî7ñ]õn�7ï�ïMóºû�ïMú7ï�÷�ÿ��ï�û�ò^ó�ø�î7ï0Sÿ�27ò�ñ7o�ï�õ.ï�ñ ô,ù î1p�ï ó�øIï ôZ��þSòVó�øIï�ü2ô,ñMøhò^ó7üZø�î7ïq�7ï]õPø�$ô,ñ�ùMøhò@ù�ï]õ|ñ ó7û-û�ï]õ�ò�ü2óT�ñMø@øhï ôTódõ|ï]õPøhñ �7÷�òIõPî7ï�û-òVóø î7ï�ñ ôPï[ñ�ÿ�ý�ù�ÿKðuðtö�ó7ò�ù�ñMøIòVó7ü�õPþ7õ,øhï ðsõ � í~î7ïsðRïMø î7ÿ�û�ù�ÿKú7ï ôjõ-ñ�÷@÷�òVó7ûKödõPø�ôPò�ñ[÷�õ �ï�ù�ò�ýTò�ù�ñxøhò�ÿKó�ñ ó7ûû�ï]õ.ò@ü2ór$î7ñ]õ.ï�õeý�ô,ÿKðs$ôPï�õPøhñ ó7û�ñMôTøhò õ.ñMøIò�ÿKóZøhÿ�ýTòVó7ñ�÷�òVð#�÷�ï ðRï ó�øhñMøIò�ÿKó �

��þ2ôPñ�î7ñ�õÌýÿKö�ô¼ðLñ�ò^ót$î7ñ]õ.ï]õi�vu�ï ôú7ò@ù�ïwu5�ï�ù�ò@ýò�ù[ñMøhò@ÿKó ; udïMôú7ò�ù[ïyx�ï[ù�ÿKðj�ÿ7õ.ò�øhò@ÿKó ; u�ï ôú7ò@ù�ïx�òIõPø�ôPòz��ö�øIò�ÿKóÆñ ó7ûmudïMôú7ò�ù[ï > ð#�÷�ï ðRï ó�øhñMøIò�ÿKó � í~î7ï�{I| }�~��z�i|�{`��|i�� V�z�i��c�z�V�O$î7ñ]õ.ï\ýÿ�ùMödõ.ï]õ�ÿKóû�ï�ýTòVó7òVó7ü�õ.ïMôú7ò�ù[ï]õ.$ôPÿKú7ò�û�ï[û\��þ ø�î7ï�õPþ7õ,øhï ð ñ ó7û ø î7ï[òVô)ödõ.ï ôjõ �d> ó�ø�î7ïj{I|�}�~��$��|+�+|��V�A��i�z�c�z�V�$î7ñ]õ.ï)ø î7ï�ñ��dõPø ô,ñ�ùMø�ðLÿ�û�ï�÷�$ôPÿ�ûKö7ù[ï�ûRñMø�ø î7ï7$ôPï ú7ò@ÿKödõ�õPøIñ�ü�ï�ò õgû�ï�ù[ÿKðj�ÿ7õ.ï�ûtòVóRñZõPøIï ��òIõ.ï�ñ ó7ûøhÿ�"B�û�ÿ��ó0ýñ]õjî7ò@ÿKó�òVó�øIÿ ñLõ�ïMø�ÿ�ý�õ.ï ôTú7ò�ù�ïtù�ÿKðj�ÿKó7ïMó�øTõ�ñMó7û ÷�ÿ�ü�ò@ù�ñ�÷"òVó�øIï ôPýTñ�ù�ï]õE�7ïMøM�Zï�ïMó�ø î7ïMð �> óRø î7ï.{I| }�~��z�i|q�j�:� �$}��z��V�c�z�V�j$î7ñ]õ�ï ; ø î7ï�÷�ÿ�ü�ò@ù�ñ�÷�ñ ôPùMî7ò^øhï[ùMø ö�ô,ï�ÿ�ý|õ.ï ôú7ò@ù�ï]õ�òIõgû�ò õPø ô,òz��ö�øIï�ûRÿKú7ï ô|ñü�ò^ú7ï ó��÷�ñxøhýÿKôTðmñMôPù î7ò�øhï�ùMø�ö�ôPï �A� òVó7ñ�÷@÷^þ ; òVó6ø�î7ï�{I|�}�~��z��|j��A��M|i��|i��z��z�V�n$î7ñ]õ.ïsø�î7ï õ,ø ôö7ùxø ö�ôPñ[÷ï�÷@ï ðLï ó�ø�õqñ ô,ï ò^ó�øhï�üËôPñMøIï�û ò^ó�øhÿ�ø�î7ïyøIñ ôPüKïMø�ï ó�ú7òVô,ÿKó�ðLï ó�ø�ñ ó7û��÷�ñMøIýÿKôð1B,õ'�ï[ù�ò�ýTò�ù�ù�ÿ�û�ï ò õü�ï ó7ïMôPñMøIï�û �

� ïfðLÿ�û�ï�÷I�ñMôTø�ÿ�ý�ñ�í~î7òVôPû 4 ï ó7ï ô,ñMøhò@ÿKó 6 ñ ô�ø ó7ï ôjõjî7ò$ 6 ôPÿ��¡ï�ùMø�� !54?6d6d� �ÿ7õ.ò�øhò@ÿKó7òVó7üSõPþ$õPøhïMð�� :9�;� �=< � � í~î7ïO�ÿ7õ.ò^øIò�ÿKó7òVó7üzõPþ$õPøhï ð $ôPÿKú7ò@û�ï]õ��ÿ7õ�ò^øhò@ÿKó7òVó7üzõ.ï ôú7ò@ù�ï]õ6øhÿºù[ñ�÷�ù ö7÷@ñMøhïaø î7ï�$î�þ$õ.ò�ù�ñ[÷÷�ÿ�ù[ñMøhò@ÿKóqÿ�ý�ñaü�ò^ú7ï ó¾ödõ.ï ô ï��Kö7ò$$ðRï ó�ø�� òVó�ñF��ó7ò^ú7ï ô�õ�ñ�÷#��ÿ��7ò�÷�ï¼í"ï�÷�ï�ù[ÿKðuðuö�ó7ò@ù�ñMøIò�ÿKóu�þ7õ,øhï ðw��\í�u � ó7ïMøM�ZÿKô¡2 �� ï�ýÿ�ùMödõ�ÿKó 6 ÿ7õ.ò^øIò�ÿKó�pgñ[÷�ù ö7÷@ñMøhò@ÿKój¢?5�÷�ò@ù�ñMøhò@ÿKó 6 ñ ô�øA� 6 p�¢ 6d� 3Lñ�ñ ô�ø�ÿ�ý�ø î7ï/�ÿ7õ.ò�øhò�ÿKó7ò^ó7üaõ,þ7õPøIï ð ñ�÷�÷@ÿ��Zò^ó7ü¼ù[ÿKðuðuö�ó7ò@ù�ñMøIò�ÿKó�ò^ó¼ø�î7ïno{ñ�û�ò�ÿF¢Zù[ù�ï]õ*õT0tïxøc��ÿKôb2�£o¤¢E0 ��

¢�õ{ñ.�ñ ô�ø"ÿ�ý~ø î7ï�oE¥7x > 0y$ôPÿ��¡ï�ùMø ; �Zï�î7ñ ú7ï�û�ï ú7ï[÷�ÿ��ï�ûSø�î7ï�ô,ï��Kö7òVô,ï ðLï ó�ø�õgû�ÿ�ù ö�ðRï ó�ø¦�� |ýTÿKôø î7ï !5476d6 �ÿ7õ.ò^øIò�ÿKó7òVó7ü\õPþ7õ,øhï ð � í�î7ï�û�ÿ�ù ö�ðLï ó�ø§$ôPï]õ�ï ó�øTõ�ø�ôPñ�ù[ï�ñ��7÷�ïXôPï��Kö7ò^ôPï ðRï ó�øTõtù[÷�ñ]õ*õ�ò�ýò@ï�ûòVó�øIÿ ! ù[ñMøhï�üKÿKôPò�ï�õi�6ñ ô,ù î7ò^øIï�ùMø ö�ô,ñ�÷ ; ýhö�ó7ùMøhò@ÿKó7ñ�÷ ; ñ ó7ûrù�ÿKðtðuö�ó7ò�ù[ñMøhò@ÿKó7ñ�÷ �v> ó ñ�û�û�ò�øhò�ÿKó ; ø�î7ïý�ö�ó7ùxøhò�ÿKó7ñ[÷7ôPïi�Kö7òVôPïMðLï ó�ø�õeýÿKô�ø î7ï 6 p�¢ 6 ù�ÿKðtðuö�ó7ò�ù[ñMøhò@ÿKó�î7ñ ú7ï§�7ï�ï óuõ �ï�ù�ò�ýTò�ï�û�ò^ó¨�� :9�; � �=< � �

9

©«ª$¬ «® ¯ ® ¬=°=® °=±£²«ª³¬« ® ¯ ® ¬«°«® °«±´«µK¶ ·¹¸«º µK¶ ·¹¸

»�»z¼¾½K¿zÀKÁ:½¾¿³Â$ÂÃcÄ ½:Å Æ Å Ä$Ç:È ÁzÉ À:¼³É Á¾Æ Å Ä$Ç

´¹Ê¾Ë£º Ê:Ë´ Ì µ:Ílº µ:Í

´ Ì Î¾Ï Ð Ñ ¸ Ò Ó Ô Õ`º ÎKÏ Ð Ñ ¸ Ò Ó Ô Õ´ ÖK· × Ø ÙMµ¡º Ö¾· × ·¹¸ · Ì Ú ·¹Ø Ù�µ

Û&ÜcÝ�ÞIßKÞIà"áãâ�äVå@àVÜ�æ�å@ä5çdèié

êMêMë'ìMí î³ï ð$ìMñ'ì�ð³òcó�ôMòMõ$ï ö ï òM÷MøcøùlúlûMü ý ü ú£þ£ü þlÿ

� ��

� ��

� ��! � �� "

� �� #%$!&� ��$"& � ��$!& � ��'�(�� '#(��

� �� )'�(��

� �*,+ �� -� � ��* + �� -�� .* + ��#� � � -� ��!

Û&ÜcÝ�ÞIßKÞ0/8ß21436571nàVæ�ç98:365;1=<�ä?>@1�äA<`Ü�BbÜcäVædÜMæ8Ý

CED0F9GHFJILK0M�NOFPGAQ6FRNOM�SLM�NRTJU,M�V2WXQYD0T[Z%F\Z]U!TJIÛ^Z_S!I]V2àNbI.FRTJU!M�W0cXTedAV2`9TRM�Wf`PVAdAFOghVAS=U D0FeZ]iYZ]U,Fb`/á0CED0FI]FOg�TJU,M�V2WHZ�D0MQjZ9k0FJU�l:FOFbWmU�D0FnZ]iYZ]U,Fbòg�FbK0FRgpZ)FbILK0M�NRF[Z9TbW0dnU D0FRM�IrqHZ%FbI)Z\k0FRNOV2`PFsNRTbW0dAM�dATJU!F[Z9S^V2It4uOvwtyx{znty|~}?��Y�O��u6�b|��[��R�;v��O�R�Jx�x{tw}0��Y��xPVAS_U�D0F�Z.i0Z]U,Fb`�g�FbK0FOg�Z)FbILK0M�NRF[Z á�ChD0FX�hGY�;�hG�TbI.Fg�VAc2M�NRTRg�M�W?U!FJI]SLTONRF[Z�TJU�U!TRNbD0FOd�U,V�U D0F�NRg�T[Z�Z%F[Z�l;M�U�D�Q6V2IÛ^Z�ásChD0F�dAV2`PTRM�W�`PVAdAFRgmSLV2I�U�D0Ft�}�xO�� }?�6��[��Z]iYZ]U!FJ`�TJW0d�M�U"Z Z)FbILK0M�NRF�t�}�xO��,��}?�6¡�¢Y£��¥¤?£�¢Y� ��}?�9M Z Z]D0V2l7W9M�W9¦§M�ce¨)á ©JT�TbW0d{�hGY�;�ªVASU D0F �@V0Z)M�U!M�V2W0M�W0c{Z.i0Z]U,Fb`«M Z¬Z�D0V2lpWeM�W{¦§M�c;¨)á ©�kdá

�K0TRg�M�d®Fb¯6FRNbq?U,M�V2W°V2I]dAFbIpVASpZ%M�c�W0TRg ZrV2W��hGY�;��NRTbW®k0FªZ.Q6FRNRM�S^M�FRd�k?iªU�D0FPNRV2ILI.F[Z]Q6V2W0dAM�W0cªqHZ%FNRT[Z)F;TbW0dXZ)FR±2q0FbW0NRF7dAM�TRc�I.Tb`fZ�á?¦§M�W0TRg�g�iY²Yl;F;SLV2I^`PTRg�g�i�dAF[Z%NJI]M�k0F³U D0FpNRV2`�`\qAW0M�NRT~U!M�V2W\k0FJU l;FRFbW9TZ]iYZ]U!FJ`«g�FJK0FRg´Z%FJILK0M�NOF_TbW0drM�U"ZµqHZ%FbI]¶.Z)·�M�W:U�D0F�Z]U!T~U!F `9TRNbD0M�W0F�T[Z4M�g�g�qHZ]U�I]TJU,FRdrM�W{¦§M�c�qAI]F ¨)á ©JN�á

¸�¸�¹ º#» ¼�½ ¾�º#¹ ¿�º�¾�½ À ½ ¾ÂÁ�Ã ½ Ä�ÅÂÆ�ÆÇ.ÈLÉ.Ê ËÂÊ È]Ì]Ê Ì^ÍÎ�Ï�ÐÒÑ Ó Ô Ó Ð�Õ�Ó Õ�Ö^×�ÏÒÐ�Ñ Ó Ô Ó Ð�Õ�Ó ÕÂÖ

ØÂÙÒÚ ÛÂÜ Ý Ù�Ú Û Ü

¸�¸Þ ß�º�¾�Á�ßÒº�Æ#Æà Ä�ß�½ Ã ½ ÄÅÂá"Á#â ¾ÒÞ�â Á�Ã ½ Ä#Å ã ä â º ß�º#» ¼Â½ Å åæ ç�èÒé ÐÒê,Ï�ÐÒÑ Ó Ô Ó Ð�Õ�Ó Õ�Öæ ç#ë Ð�ÏÒÐ�Ñ Ó Ô Ó ÐÒÕ�Ó Õ Ö

ì�í ç�é î�ï

ì í ç í Õ ðìÂí ç ð ÎÒÓ ñ ç íÂÕ ð

ò óÒô Ú ÛÂÜ

Û&ÜcÝ�ÞIß�õ�à"áãâ�äVå¨àVÜMæ�å@ä5çdèié Û&ÜcÝ�ÞIß�õ[/Zá¥14365;1nä?>@1�äA<`Ü�BbÜcäVædÜMæ8Ý Û&ÜcÝ�ÞIß�õ�öißY3jB à2B'èqç)ÜMà5ÝA÷�àVå ä?>3Aø´<%B'è�å 1436571®ö�äVå¨åfùdædÜ ö�à2BbÜcäVæ

CµV�M�`\Q6g�Fb`PFJW?U�M�U"Z\V2lpW�Z%FbILK0M�NRF[Z�²µU�D0FsZ]iYZ]U!FJ`úqHZ�q0TRg�g�i�qHZ%F[Z\FJ¯YU,FbILW0TOg�FbW?U,M�U!M�F[Z áµCED0FsZ%FJILK0M�NOF[ZQYI]V2K0M�dAFRd°k?i®U D0F�Fb¯AU,FbILW0TRgûFbW?U,M�U!M�F[Z:Q6TJIÛ!MU!M�V2W�Fb¯6FRNbq?U,M�V2W�VAS_U D0F�tw}�xb��,��}?�6¡�¢Y£��¥¤?£�¢Y� ��}?�üZ)FbILK0M�NRFM�W?U,V7U D0F_NOV2ILI]F¥Z]Q6V2W0dAM�W0c{Z.U!TRc?F¥Z á

ý,W�U D0F�W0Fb¯AU§þPu6�b|��R�_ÿ{�R�R}��¬}�xO�� }?�:þPQYD0T[Z%F³l;F7M�W?U I]VAd2q0NOF7Fb¯AU,FbILW0TRg@Z%FJILK0M�NOF³QYI.V2K0M�dAFbI�ZwM�W?U!VU D0F{dAV2`9TRM�Wf`PVAdAFRghNOV2WHZ]U I^q0NJU!FRd9QYI]FJK0M�V2qHZ%gi0²´T[Z�Z�D0V2lpW�M�Wª¦§M�cX¨)áÂŸT�áHCED0F:`PVAdAFRghM�W0NRg�q0dAF¥Z U�D0FFb¯AU!FJILW0TRg Z%FbI^K0M�NRF QYI]V2K0M�dAFbI)Zsÿ�� TbW0d v³£��´}2|b��já;ChD0F g�VAc2M�NRTRgXM�W?U!FbI.SLTRNRF¥Z�TbI.FTJU�U!TRNbD0FOdrU,VrU�D0FpNOV2ILI]F¥Z]Q6V2W0dAM�W0c{NRg�T[Z�Z%F[Z=K0M�T Q6V2IÛ"ZyNRTRg�g�FRd��=uOvwt4xyz��=x~�O�:u6�O��O�µv��O�R�Jx�xyt�}0��Y�xT[ZhQYI.F[Z%FbW?U,FRdrM�W{¦§M�c;¨)áÂ¨?kdá

10

�� "!#� $&%�� $(' ) *,+.- /1032�/.4 5 6 5 /�7 5 7 8

) *,+ - /10:9�;

) *<+ - /�0�=�> 8 /�- 5 6 ? 0) *<+ - /103@�A

B�CED F G(H<I J3FLK�MNG�F O3D H&G�CED F G(H<I J3F ) *<+ - /10:P QN@�R<S.7 T.> U.-) *<+ - /10N9�;,R<S.7 T.> U.- ) *1V,/�2,/.4 5 6 5 /,7 5 7 8

W X,Y&Z [.\

W X,]�^�_&` a1b�c [1\

W X d�c e.f�\ g h i.jW X�Y�k

W X�l1m(Y�_&`.a b,c [ \W X1d(c e.f,\ g h i.jN_&` a b<c [1\W X,Y�k,_&`.a b,c [1\

W X1Y&Z [1\

W X�n f�Z g h g f1a�g a.e W X�n.f.Z1g h g f�a1g a e

W X,n f1Z1g h g f�a1g a e W X,n f.Z.g h g f1a1g a1eW X,]�^ W X,l.m(Y

) *�+.- /10:@�A&R<S 7 T > U - ) *<+ - /,0(=�> 8 /�- 5 6 ? 03R<S 7 T.> U.-

) *1V</�@�A,R&S 7 T > U - ) *1V,/ =(> 8 /1- 5 6 ? 03R&S 7 T > U -

) *1V,/�P QN@�R<S 7 T > U -

W X,]�^

W X,Y�k W X1d(c e1f�\ g h i1j

W X,l.m�Y

) *.V,/,9�;<R<S.7 T.> U.-

) * V</,@�A

) *<+ - /103P QN@

) *1V,/ =(> 8 /1- 5 6 ? 0

) *.V,/<P QN@) * V</,9�; o(pLqsr�pLqEt3o&u(v:w x(y o�z�{#|sr�z({#|LtLo<u�v}w x�y

o�u�|E~�r}|�~}t3o�u�v3w x(y o<u(�Ew ��r��Ew �}�:t3o&u(v3w x(y

�,� � � ��#�,�&�(�<� �&� �.�<�3��.�<��,�1� � � �,�1�<��1� ��1�

��,��¡ £¢:¤��¥�¦§¥�¨��ª©�¢� �«��¡ #��¨�«

¬�¯®£°�±�²�³:Ńµ·¶3¸¹±»º£±�¼�½¹³�º£±�¾¯®£¶L¿�À�±s®Á�´Â®Ã±¡º#Ä¹³}²�±Å³�ÆÇ°�È}±¡ÆÉ±�Ê�¶L¿�¶N³:�ÊÌË�Í·±Î¾�±�²ª�ÆÇ°�¹®"±Ï¶:¸¹±ÑÐ¹±¡¸¹¿¡Ä¹³:�½�º��´¶3¸¹±�ÆÉ¿�³(ÊÉ½Ì®"±·²�¿Ò®Ã±Ò®Ï¿�²�²ª�º�¾�³�Ê¹À�È(µÌÓÔ¬�¸¹±Õ´�½�Ê¹²�¶N³:�Ê¹¿�È�¿¡º£²¡¸¹³(¶N±�²�¶3½�º£±Ö³3®×¾�±�É³�Ê¹±�¾¯³(Ê ¶L±�º#ÆØ®Ù�´Ú®Ã±¡º#Ä¹³}²�±²��ÆÛ°��Ê¹±¡Ê�¶E®ÜË�ÍÕ¸¹³}²¡¸É±�Ê¹²�¿�°§®Ý½¹È}¿�¶L±Å´�½�Ê¹²�¶L³:�Ê¹¿ªÈ:³(¶N³:±Ò®Þº£±�È:¿�¶N±�¾·¶LÛ¿Ö®Ã³�Ê¹À�È}±�±�ßÌ±ª²¡½�¶L³}�Êà®�¶N¿�À�±Å�ºÂá¶3¸¹±�ºÈ:�À�³:²�¿�ÈÅ°�³:±�²�±â�´ ´�½�Ê¹²�¶N³:�Ê¹¿�È}³(¶:µÌÓÙãNÊåä�³}ÀçæèÓ.æÔ²�Í·±é°Ôº£±Ò®"±¡Ê�¶Ö¶3¸¹±ê¿¡º£²¡¸¹³(¶N±�²�¶:½�º�±ê¾�³}¿�Àáº�¿�Æë�´ì¶:¸¹±íÁîáïªð�ñ3ð�î�ò�ð�òÒó®�µÔ®�¶L±¡ÆôÓè¬õ¸¹±ÛÆ¯¿�³�Êö±ªÈ:±¡Æ¯±¡Ê�¶EËè÷�ø�ùûúüð�ýªøûþ ð&ù�ø�ý�ñ}î�ùÝÿÂ°�È}¿�µ¹®Ñ¶3ÍÖ º��È}±Ò® � ³(¶ÞÆÉ¿¡Ê¹¿ªÀ�±Ò®»¶:¸¹±±¡ß�±�²¡½�¶N³:�ÊÛ²��Ê�¶:º��È�³�Ê·¶3¸¹±Î®�µ¹®£¶L±¡Æ ¿¡Ê¹¾Ö¸¹¿¡Ê¹¾�È:±s®�¶3¸¹±»²ª�Æ Æ ½�Ê¹³}²�¿�¶N³:�ÊÛ�Ê·¶3¸¹±��Ó

��¢Õ�� ·¨��ª©�¢� �«��¡ #��¨�«»¤��Ü«ª¨��§¢3��«��¢��" �¨¡¢��è £¢3¤��

¬õ¸¹±ØÆ¯�¾�½¹È:¿¡º·®�µÔ®�¶L±�Æ Æ¯�¾�±�È °Ôº��¾�½¹²�±ª¾�¿�¶Ù¶3¸¹±��±¡º#Ä¹³}²�±��Ö±�²ª�ÆÇ°�¹®"³�¶L³:�Ê °Ô¸¹¿Ò®"±Ø¿�È:È}�Íì®Ö½Ì®Õ¶L¿¡Ê¹¿�È�µ¹®Ã±ÎÄ¹¿�º�³:�½Ì®Ú¾�³3®�¶3º£³�Ð�½�¶L³}�ÊÇÆ¯�¾�±�ÈN®�ÓáãNÊì¶3¸¹±»Ê¹±¡ß�¶§°Ô¸¹¿Ò®"±��±¡ºEÄ¹³:²�±��Õ³N®�¶:º�³(Ð�½�¶L³:�Ê �Ç¶3¸¹±�®Ã±¡º#Ä¹³}²�±²��ÆÛ°��Ê¹±¡Ê�¶E®Ï¿�º�±·¾�³3®�¶3º£³�Ð�½�¶L±ª¾É�Ä¹±¡ºÁ¿·À�³�Ä¹±¡ÊÉÊ¹±�¶:Í·�º"!Ø¿¡º�²�¸¹³(¶L±ª²�¶3½�º£±�Ó#��³:ÀáÊ¹¿�È}È:³(Ê¹ÀÛ°Ôº�á¶N�²��ÈN®Ï¿ªÈ:È:�Í´#�ºõ²��Æ ÆÇ½�Ê¹³:²�¿�¶L³:�Ê Ð¹±�¶3ÍÖ±�±¡Ê·¶3¸¹±Î®"±¡º#Ä¹³}²�±»²��ÆÛ°��Ê¹±¡Ê�¶E®Â³�ÊÛ¾�³N®£¶L¿¡Ê�¶ÌÊ¹±�¶3ÍÖ�º$!Û±�È}±¡ÆÉ±�Ê�¶E®�Ó

ãNÊ ä�³:À æèÓ&% Í·±�³}È:È(½Ì®�¶3º£¿�¶L± ¶:¸¹± °Ô¸�µ¹®"³}²�¿�Èà®£¶3º#½¹²�¶3½�º�±��´à¶3¸¹±�¾�³N®£¶3º�³(Ð�½�¶L±�¾ °�¹®"³�¶L³}�Ê¹³�Ê¹À ®�µÔ®�¶L±�Æ�ÓíÁîáïªð�ñ3ð�î�ò�ð�òÒó�')(�*Ïþ ¿�Ê¹¾ÇíÁîáïªð(ñNð(î�ò�ð(òÒó�'¹÷,+Ï÷àº�±�°Ôº£±Ò®"±¡Ê�¶�Ê¹±�¶3ÍÖ�º$!Ø±ªÈ:±¡Æ¯±¡Ê�¶E®Ï³(ÊØ¿�-�.â¬/�ØÊ¹±�¶3ÍÖ�º$!�Ó0�±éÆ¯¿�°�¶3¸¹±ê´L½�Ê¹²�¶L³}�Ê¹¿�ÈÖ¿�º�²¡¸¹³�¶L±�²�¶:½�º�± ¶N ¶3¸¹± °Ô¸�µÔ®"³}²�¿�ÈÖ®�¶3ºE½¹²�¶3½�º£± Ð�µ ³�Ê¹²�È(½¹¾�³�Ê¹Àâ¶3¸¹±â®Ã±¡º#Ä¹³}²�±²��ÆÛ°��Ê¹±¡Ê�¶E®»³�Ê�¶NÉ¶:¸¹±·Ê¹±�¶3ÍÖ�º$!ô±�È:±�ÆÉ±¡Ê�¶�®�ÓÌ¬õ¸¹±ì´�½�Ê¹²�¶L³:�Ê¹¿ªÈ:³(¶}µØ�´Â÷�ø¡ùÜúüð�ý�øÜþ ð&ù�ø�ý�ñ}î�ùÖ®�°�±�²�³}´#³:±ª¾Ø¿�¶¶3¸¹±1��±¡º#Ä¹³}²�±2�Ö±�²ª�ÆÇ°�¹®"³�¶L³:�Ê °Ô¸¹¿Ò®"± ³N® ¿�ÈN®Ãå¾�±�²ª�ÆÇ°�¹®"±�¾ ¿¡Ê¹¾ ¾�³N®�¶:º�³(Ð�½�¶L±�¾ �Ä¹±¡º¯¶3¸¹±À�³(Ä¹±¡ÊÊ¹±�¶:Í·�º"!�Ó

354 687:9 ; <:6�; ="4 <�>?9 @:AB4 @$C

D EGFIHJKML�NMOIN

D PRQ�STUGTWVIX:YITIZ [ Z Y:\IZ \]G^8_:à_

b,cWVIX8Y8TZ [ Z Y:\IZ \]G^$dfeBg

hGikj l monqppr:ns mGl itnufl vkj s l w�xMj l y�z�{{|iM} hGvtv?~:yGvMl j l yz�l zM�

D EM�I�D EG�I�D EG�I� D EG�I�

D PRQ&SD EG��D EkO8� �RLk� � � �R�

D EM�R��D EtOI� �kLR� � � ��

D EoNMOINMKMLkFIHJ

D EG��R�

D EG��k�

11

��M��,��o��?�� ¢¡|£¥¤§¦M¨,¡ª©a«¬/®G¡,« ¡q¯�°G±�°I¦o²�¯´³��¶µa�¸· �¹µ�³¢�5º5�G»8�¼��½¾· ��À¿��MÁ"��Â��5�ÄÃ�ÅÇÆº5½¾ÈÉÈÊÂ)��º,�|�8�G½¾�ÌË��?�· �5�q�¹�q��8�t�8�G�¶µÍ�M�¹Î)��»"»$�qÁB�q��1��|��·Ï½¾Á"Ð ��½)Î)�¶µÑ�µÒÁ��5�,��GÓ¶�,ÎÔÂÕµÖ�M��×Ø��Â)��Î)�qÁB�o��M��×Ù�Á��|�Õµ�³¢½¾Á"�1µÖ�qÁ"¿��º5�Wµ|ÚÜÛ��ÝÎ)�|�8�,��,ÎªÎ)�µÖºqÂÕµ�µÖ�G½¾�À½)»Þ��IµÒµ��I�5×��Ýº5�q�ØË��Ý»$½¾Â)��Î�5�µÖ�q·Ç��qÁ��àßMáâÚ&ã��áâÚkä¾��áâÚ&å�æçÚ

è¢é�ê¢é�èìëîí)ï,ðòñ�óâôâõ5ï�ö#÷�ø5õ,ù$úÊï,÷�õ,ûâü�õ5ýÿþ õ�öâõ,óí��ðòõ,ûâüÛ�� |��½)Î ßGáâÚ��æ �Iµ �q��|³)³�ÁB½)�5ºq�Ü»$½¾Á �� M��Î¾ÂÕµ��Á��G�5��Î)�q¿��5��½�³�Èÿ�q�� ½)»/��×��t� Î)�|³¢�q��Î)�qË��G�µÖ½)»I�· �qÁ��¾Ú Û��ÄÎ)�q¿��,��½�³�È �|��ÜÈ �?��½)Î)½)��½)×¶� �5Î)½�³)�I�5ÎÍË�� µ µ��I�|³�·Ï�µÖ� ÁB�5»$�o��qÈ �q��BÚ1��qÈ ³¢��½��Ç�� |��½)Îà�¶µ ��»"½¾Á$Èÿ�5�Õ»8Á��qÈÿ�q·Ï½¾Á"Ð »$½¾Á ¿��qÁ��G»8��M��×Ç�� Á��Î)�q¿��,��½�³�È �|��Õ³�Á�½)º,�¶µ�µ|Ú�I�� Á��¶�#�� ½��I��½¾� ½)» � µa�qÁ$¿��Gº5�Êº5½¾È ³¢½¾��q��/�IµÇº,�q��ÁB�5��I½ ��É�q��8�oÁ��ÉÎ)�q¿��5��½�³�Èÿ�q��³�Á�½)º5�Wµ�µ|ÚÛ��qÁ��,»$½¾Á��W��8½ »$½¾Á"È �5�G�IµÖ�� Á�� M� �� |��½)Î��· �ÿ��q¿��Ê�8½ µ��8�qÁ:��Ë��È ½)Î)�,��o��× ��µa�qÁ$¿��Gº5�º5½¾È ³¢½¾��q��o�Ï�� µ�³¢�5º,��»$�Gº5�|�I��½¾��|��×�Â��5×��¾Ú� µÖ�qÁ"¿��º5��º5½¾È ³¢½¾��q�� ¶µ ��·Ï½Ñ�¶µ�µÖ�|��8��,�ÿ³¢�|Á"�"µ��ì»8Â)��º|�8�G½¾��5��q��ÎÍº,½¾ÈÊÈÊÂ)��Gº5�|�I��½¾��5�:ÚÏÛ��»:Â)��º?�8��½¾��,� ³¢�qÁ:�ì�Iµ ��qÈ �µ�µÖ�G½¾�� ½)»Ê�2µa�qÁ$¿��Gº5� º5½¾È ³¢½¾��q��"��:Ú��¾Ú��2µa�qÁ$¿��Gº5��Bµ��É·Ç��ºq� �t�à�µº5�|³¢�|Ë�� ½)»ì��¢�5º|Â��8�M��×¢Ú/Û�� º,½¾ÈÊÈÊÂ)��Gº5�|�I��½¾��5��³¢�qÁ:�Ï�µ��|�1�M��I�qÁ�»"�5º5��¿��·��Gºq�Þ�� µa�qÁ$¿��Gº5�º5½¾È ³¢½¾��q�� Á��,º5�5�M¿��Wµ Á�� ¾Â��¶µB�"µ��I½ ��¢�5ºqÂ��8�2�� µÖ�|Á$¿��º,� �q��Î�µÖ�q��Î�µÜ��ÞÁB�¶µfÂ��o�:µ ½)»�µa�qÁ$¿��Gº5��¢�5ºqÂ��I��½¾��ÚÆàµfÂ��5��t� ��¢�5ºqÂ��I��½¾� ½)» � µÖ�|Á$¿��º,�´�o�)¿�½)�M¿��¶µÀº5�|Á"�8�,�M� º5½¾ÈÉ³�Â��I�|�8�G½¾�Õµ|Ú�1� º5�,��Ñ��!�Á��?³�Á��¶µÖ�|��8�|�I��½¾�"�� º5½¾Á$ÁB�¶µ�³¢½¾��Î)�o��×òÎ)�|�I�É�|��Î�½�³¢�qÁB�|�8�G½¾�Õµ#� ½)»/��Iµ ³¢�qÁ:� ½)» µÖ�qÁ$¿��Gº5�ìº5½¾ÈÉ³¢½¾��|��q�%$'&)(|°o£¥±�¨5°+*,$ ®G¨�-�®G±�°¦o¯/.10 ±�¨32¢¦o¯�¡�4 $%*5$60%7�Ú�Û��Çº5½¾ÈÉÈÊÂ)��º,�|�8�G½¾��5�Õ³¢�qÁ"� �Iµ º5½¾Á"Á��¶µ�³¢½¾��Î)�o��×��o�º5�5�G��5Î8$'&)(|°M£¥±�¨,°9* ²�«Ç«:-¾¯¢¦o¨,±�°I¦t¯/.;0 ±�¨32¢¦o¯�¡14 $<*=0<7?>î�q��Îò�t� �M��º5�oÂ�Î)�¶µ ��ìÎ)�|�I� �|��Îò½�³¢�qÁB�|�8�G½¾�ÕµÈ ½)Î)�,��o��× �� º5½¾ÈÊÈÉÂ)��º5�|�I��½¾� ºq��|�)��5�Iµ Ë��?�· �5�q� � µa�qÁ$¿��Gº5� º5½¾È ³¢½¾��q��À�q��Î �o�:µ�q�)¿��oÁ�½¾�)È �|��ÚÒÛ�� q��I�MÁ��@� Èÿ½)Î)�5� ½)»ª� µÖ�|Á$¿��º,� º5½¾È ³¢½¾��q�� µÌº5�,��,Î!$'&)(|°M£¥±�¨,°* ²�«�«8-¾¯¢¦M¨,±�°¦o¯/.�* ²�«¬/²�¯�¡q¯�°A4 $<*6*B7�Ú�I�C ��Á��Ü� ��µÖ�|Á$¿��º,��º5½¾È ³¢½¾��q�� µàÂÕµfÂ��,��o� ÁB�|³�Á��¶µa�q��8�5Î �¶µ �q� �5º|�I�M¿�� º5��¶µçµÏ· �o�� ÃED � Ã�|�G�8�5ºq��,Î �8½ �o� ¿��ÿ��ÿ³¢½¾Á"�BÚ+�I� �,Î)Î)�o�8�G½¾�Õ��Üµ��I�|�8� Î)��,×�Á��qÈ¹Î)�|³¢�Gº|�"µ µÖ�G×��5��G�M��× µÖº5�q��|Á��½ ½¾�ÃED � Ã �o��º5�MÂ�Î)�o��×ì��ÏµÖ��×§��5�Iµ�»:Á�½¾È �q��Î �I½ ��ÏµÖ�qÁ"¿��º5��º5½¾�ÕµfÂ)È �|Á�ÚGF µ�µa�q��8�G�5��t�à��¶µÖ�ÇÎ)��,×�Á��qÈ�µµfÂ�»"»$��º,�2�8½ µ�³¢�5º5�G»8� �� µÖ�qÁ$¿��Gº5� º,½¾ÈÉ³¢½¾��q��ÿ�5º5º5½¾ÁBÎ)�M��× �8½1�� ³¢�|��I�qÁ$�C$<*6*�Ú�Û��Þ×¾�q��qÁ��,�³�Á��o��º5�o³¢�G��½)»��Á��q�Õµa��|�I��½¾� �Iµ µf��½¾·�� o�ì��× áâÚIHâÚÛ�� Æ<�� á�Î)�WµÖºqÁ��t³)�8�G½¾� ½)» ÃED � Ã2½)»�µÖ�|Á$¿��º,�Êº5½¾È ³¢½¾��q��=J ²)(,¦o°I¦o²�¯¢¦o¯/. �µ��Á��q�Õµa��|�I�5Î��o��8½��$%*K0 ³¢�qÁ"� ½)»��L� È �5ºq��o��M6NONKPRQASBT�U VWU SYXZUIX)[�\ìÛ��$%*5$O0 ³¢�qÁ:��½)»�M]NON=PRQASZT�U V^U SYXZUIXG[º5½¾��I�5�M�Õµà�Üµa�M��×��G� ½�³¢�|Á��|�I��½¾� ·��Gºq� �|ËÕµ��ÁB�5º|�8�t��È ½)Î)�,�IµÏº5�5�GºqÂ��|�I��½¾� ½)» �q� �|³)³�Á�½G�¢�MÈÿ�|�8�ÿÂÕµÖ�|Á³¢½�µÖ�t�8��½¾��Ú¶Û��¶µa� �ÁB�q�ÕµÖ��?�8��½¾�Õµî»$½¾Á$Èÿ�5��µÖ� �� ¢¡q£¥¤§¦o¨5¡ �ç¬/¡5¨W¦ _)¦o¨,±�°I¦o²�¯ ³��¶µÖ��½)», ��Á��¾Ú�I� ��)��³��¶µa��½)»8 ��Á��Î)�q¿��5�G½�³�È �q��6` �¢¡|£¥¤§¦M¨,¡�a ¡5¨,²�«¬/²)(,¦o°I¦o²�¯b`Þ· �ÜÎ)�5º,½¾ÈÉ³¢½�µÖ� ��³¢½�µÖ�t�8��½¾��o��×¹µÖ�qÁ$¿��Gº5� ³�Á�½¾¿��GÎ)�5Î¸Ë��Ô��ªµÖ�qÁ"¿��º5� º5½¾È ³¢½¾��q�� M��I½¹�Ù�)Â)ÈÊË��|Á�½)»�µ��8�5×¾�¶µ�Bµ�Â)ËÕµÖ�qÁ$¿��Gº5�¶µ#�ÖÚ Û�� µÖ�qÁ"¿��º5� º5½¾È ³¢½¾��q��º5�q� ��¢�5ºqÂ��I��º5�qÁ:�8�5�o�1µ�Â)ËÕµÖ�qÁ$¿��Gº5�¶µÊ�t�"µÖ�5�G»Ï�¶µ · �5��¶µÁ��3�¾Â��¶µ��Õ��)�8�|Á$��5�#µÖ�qÁ$¿��Gº5��º5½¾È ³¢½¾��q��"µ�8½àÎ)½à�o�BÚ � �¢�� ¢¡|£¥¤§¦M¨,¡ca ¡,¨5²�«¬/²)(q¦M°I¦o²�¯ ³��¶µÖ� ��·Ï½È �ed�½¾Á ��Á��q�Õµa»$½¾Á$Èÿ�|�8�G½¾�Õµ �qÁB� ³¢�qÁ�»"½¾Á$Èÿ�5Î5�

12

fBg�hBi�j k)lAg�hGh3m n�o�prq stq ovu#q uxwycz{ n�l�|?g)}/j { k/~�)�� m3� �#�� q s �� m3� �#p ��)��3�� v� �#� � ��s �l�k)��

��

�� ¡ �� ¢t� � �£� ��

¤ ¤ ¤

¤ ¤ ¤¥=¦¨§<©«ª�¬Zª��®3¯�°A±r²³¯G´x¦µ°,§8¶<·¹¸O©�º¼»B½,¾�²Y¦¨°¿´x»8´xÀ,¾6Á:Â<ÂÄÃ,¯G´Å´Æ¾3®3°

ÇÉÈ³Ê�ËÍÌ#Ë�ÎÅÏ�ÐµÑ ËÒË�Ó«Ë Ñ�Ô�ÈÕÐ¨ÖG×�Ð³ÌÙØBË Ñ ÖGÚ�Û«Ö�ÌrË ØÜÐ£×�ÈÕÖÜÝ]×BÔBÚßÞ�Ë?ÎEÖBàEÌxÈ^Ý á�Ë�Ì9âeÖGÎ=Ì�ÔBÞYÌrË�ÎeÏ�Ð¨Ñ Ë/Ì�ã�äGÝ�×�ØÇÒÑ3ÖGÚßÚßÔB×�ÐµÑ Ý?ÈÕÐ¨ÖG×æå:ÐçÈ³Ê"È³Ê�Ë�Ë�ÓBÈ^Ë�Îe×�Ý ècË�×�ÈÕÐ�È^ÐµË/Ì:Ë�Ó«Ë Ñ�Ô�ÈÕÐ£×�á;È³Ê�Ë/Ì#Ë;ÌÆÔBÞYÌrË�ÎÅÏ�ÐµÑ Ë/Ì:ÐÕÌ8Ð�×�È³ÎxÖBØGÔ�Ñ Ë ØÏ�ÐµÝ]é�ê�ë<ì+Ì?íî Ý Ñ�Ê:È¨ÎÆÝ�×YÌràeÖGÎÅÚïÝ?È^ÐµÖG×�Ñ ÖGÎÅÎxË/ÌÆÛ«ÖG×�Ø�ÌEÈÕÖÜÝÍÌrË?Û«Ý�ÎxÝ?È^Ë6ÎÆË àeÐ£×�Ë�ÚïË�×�ÈAÌÆÈÕË?ÛðÐ£×�ÖGÔBÎRÝ?ÛBÛZÎÆÖBÝ3Ñ�Ê5í

ë8Ñ Ñ ÖGÎÆØBÐ�×�áðÈ^Ö1ñAò)ÎÆÝ/ä�È¨Ê�ËÜàÅè¨ÖGåóÖBàKÈ³Ê�Ë�Ì#Ë�ÎÅÏ�ÐµÑ ËÜË�Ó«Ë Ñ�Ô�ÈÕÐ¨ÖG×¼ÐÕÌ�ÖGÎxÑ�Ê�Ë/ÌÆÈ¨ÎÆÝ?ÈÕË ØßÞ�òðô«õ?öø÷úù£û3õ'üßù�ö�õ û ýµþGö�íÿ È�Ð£ÚðÛ«èµË�Ú1Ë?×�ÈeÌ<È³Ê�Ë1Þ�Ë�Ê�Ý�Ï�Ð¨ÖGÔBÎ<ÖBà'ìEêZë8ì ÖBà�È¨Ê�Ë ÌrË?ÎÅÏ�Ð¨Ñ3Ë¼Ñ ÖGÚ�Û«ÖG×�Ë�×�È�Ý/Ì�ÌÆÛ«Ë Ñ ÐµàÅÐ¨Ë3ØbË Ý�Îxè¨ÐµË�Î#ä=Ý/Ìå8Ë è¨è]Ý/ÌðÑ ÖZÇWÖGÎÆØBÐ£×�Ý�È^Ë/ÌðË?ÓYË3Ñ�Ô�È^ÐµÖG×�Þ�òbË�× � Ô�Ð£ÎxÐ£×�á"È¨Ê�Ë�ÎxË � Ô�Ð£ÎxË Ø�Ì�ÔBÞYÌrË?ÎÅÏ�Ð¨Ñ3Ë/Ì�à^ÎÆÖGÚ È³Ê�Ë;Ë?ÓZÈÕË�ÎÅ×�Ý3èË�×�ÈÕÐ�È^ÐµË/ÌÙÝ Ñ3Ñ ÖGÎÆØBÐ�×�á%È^Ö<È¨Ê�ËÒØBË àÅÐ�×�Ë ØÜË�Ó«Ë Ñ�Ô�ÈÕÐ¨ÖG×�àeè¨ÖGåðíê«Ë�ÎÅÏ�ÐµÑ ËïÑ ÖGÚ�Û«ÖG×�Ë�×�È��cþ��3ù�ýÕù�þ��«ù�� ÌÆÛ«Ë Ñ3Ð¨àÅÐµË Ø;Þ�ò�È³Ê�ËðÚïÝ Ñ�Ê�Ð£×�Ë�� ÎxË è¨ÐµË/Ì%ÖG×;È¨Ê�ËÛZÎÆÖGÏ�ÐµØBË Ø Ì�ÔBÞYÌrË�ÎeÏ�Ð¨Ñ Ë�Ì ü! �"$#%�$&('Zùçö*)�+ ,-#�"$#%�$&('Zùçö*)5ä .0/1,-"$/æõ32��4')ö�õ458õ3�Zý³ä Ý�×�Ø687 ¿þGö�ù�ý:9$5;"�<=�B÷�þBû42ZýÕù£þ��¿í?>CÖGÎxË ÖGÏ�Ë�Î�äðÈ¨Ê�Ë ÌÆÈ^Ý�È^Ë�Ú1Ý3Ñ�Ê�Ð£×�Ë ÖBàæô«õ?öø÷úù£û3õ üßù�ö�õ û ýµþGöÄØBË àeÐ£×�Ë/ÌCÈ¨Ê�ËØBË/ÌrÐ�ÎÆË Ø;ÖGÎÆØBË�Î�ÖBà]Ë?ÓYË3Ñ�Ô�È^ÐµÖG×5í ÿ ×A@�Ì�Ô�Ñ�Ê"ØBË3Ñ ÖGÚðÛ«Ö�ÌrÐçÈ^ÐµÖG×�Ñ Ý�×¼Þ�ËÎxË?ÛZÎÆË�ÌrË�×�È^Ë3Ø;Ý/Ì'ÝÎxË àÅÐ�×�Ë�Ú1Ë?×�ÈÖBà5È¨Ê�ËÒÝ�ÞYÌÆÈ¨ÎÆÝ Ñ�ÈÉÚ1ÖBØBË3è��B � ��$�� C� ��,íD ÖðØBË?ÎÆÐ£Ï�Ë]È¨Ê�Ë]Û«Ý?È¨ÈÕË�ÎÅ×ðàeÖGÎ+È³ÎxÝ�×YÌrè¨Ý�È^Ð£×�á8é!>�ñ�E�ØBÐµÝ á)ÎÆÝ?Ú�ÌKÚ1ÖBØBË3è¨è¨Ð�×�áÜàWÔB×�Ñ?ÈÕÐ¨ÖG×�Ý èYÝ�×�ØØBÐÕÌÆÈ¨ÎÆÐ£ÞBÔ�ÈÕË ØÌrË�ÎeÏ�Ð¨Ñ Ë�Ý�ÎÆÑ�Ê�ÐçÈ^Ë Ñ�È³ÔBÎÆË�Ý?ÈYÈ¨Ê�Ë/ÌrË6È¨å:Ö<ÛZÊ�Ý/Ì#Ë/Ì=å8ËÍÌ�Ê�ÖGÔ�è¨ØÜÑ3ÖG×YÌrÐ¨ØBË�Î,È³å8ÖÜá�Ë�×�Ë�ÎxÝ èYÑ3Ý/ÌrË/Ì3FG ã,È¨Ê�ËÍÌrË�ÎeÏ�Ð¨Ñ Ë�ØBÐ£ÎÆË3Ñ?È^ÖGÎRÖBàH�cþ��3ù£ý³ù£þ��«ùI�1ÐÕÌKJ Ñ3Ë�×�È³ÎxÝ è¨ÐML/Ë Ø$N/äGÐeí¡Ë)í�äGÐ�ÈÉÎxË/ÌrÐµØBË/ÌÙÖG×�ÝÍÌrÐ�×�á�è¨Ë

×�Ë?È³å8ÖGÎPO�Ë3è¨Ë�ÚïË�×�ÈeäEBã9È¨Ê�ËðÌrË�ÎÅÏ�ÐµÑ ËØBÐ£ÎxË Ñ?È^ÖGÎ6ÖBà��Oþ��ù£ýÕù�þ��«ù��"ÐÕÌ;J3ØBÐÕÌÆÈ¨ÎÆÐ£ÞBÔ�ÈÕË Ø$N/äÉÐeí¡Ë)í�ä¿ØBÐµàÅàeË�ÎÆË�×�È+Û«Ý�ÎeÈWÌ�ÖBà Ë�Ó«Ë Ñ�Ô�ÈÕÐ¨ÖG×

àÅèµÖGå!Ý�ÎxËCÖGÎÆÑ�Ê�Ë/ÌxÈ³ÎÆÝ�È^Ë Ø¹Þ�òÄØBÐ³ÌÆÈ^Ð�×�Ñ?ÈßÌrË?ÎÅÏ�Ð¨Ñ3ËCØBÐ£ÎÆË3Ñ?È^ÖGÎ�Ì�ÎÆË/ÌrÐµØBÐ£×�á ÖG× ØBÐ¨àeàÅË�ÎxË�×�È:×�Ë�È³å8ÖGÎPOË è¨Ë?Ú1Ë�×�ÈWÌ?í D Ê�Ë Ì#Ë�ÎÅÏ�ÐµÑ Ë�ØBÐ£ÎxË Ñ?ÈÕÖGÎ#Ì¼Ñ ÖGÚðÚßÔB×�ÐµÑ Ý?È^Ëæå:ÐçÈ³Ê Ë Ý Ñ?Ê Ö)È³Ê�Ë�Îðå<Ê�Ðµè¨ËæÛ«Ý/Ì�ÌrÐ£×�á È¨Ê�ËÑ ÖG×�È³ÎxÖBèYÖGÏ�Ë�Î,È³Ê�ËÒÑ3ÖGÎÅÎÆË�ÌÆÛ«ÖG×�ØBÐ£×�á%Û«Ý?ÎeÈeÌKÖBà5È³Ê�Ë�àÅè¨ÖGåðíÿ ×ßÞ�Ö)È¨Ê1Ñ Ý/Ì#Ë/Ì9È¨Ê�ËÍÚïÖBØBË è¿ÖBàKÌrË�ÎeÏ�Ð¨Ñ ËÍÑ ÖGÚ�Û«ÖG×�Ë�×�È,ì,Ö�ÌrÐ�ÈÕÐ¨ÖG×�Ð�×�áÜå8Ð�È¨Êðé�êZë8ì+Ì è¨ÖBÖ�OYÌ Ý/ÌOÌ�Ê�ÖGå%×ßÐ£×Q Ð¨á«íRE¿í�E�Þ5í

S TVU�W XZY\[�X^]M_ ` _ XZaZ_ a:bS T*cVXZ[CX:]M_ ` _ XZa^_ aMb

dMegfih j h elkgh kimonMd:p�q�d

13

r*sut^v(wyxVzM{}|~t%�3�|=w��z�t�z*|8w��|��t*��|=w�{P�(w�tZv(��t�|=w4{V�(z^��w��s(w4s�t��4�M�*��A��^��|��{��$�:w?�$xtZv(w�|=w4{P�(z:��w��s�|��$��w4{�xP��{�tZv(w!��{P{~w|��s(�$zMs(� |=w4{V�(z^��w!��y��s(w4s�tC|K¡£¢-¤�¥-¦-¤¨§�©1¥ª��s(�8«�§K¬�®1w¯|��w��z:x��°t^v(w|=w¯|=w4{V�(z^��w±��s(w4s�tV| �|²|=w\��4{��t*w³��4v(z�s(w| ��{~�$zMs(�´t��°tZv(w��{~��(|=w��t:t�w4{Vsµ«£¶�¶%·A¸�v(w¹��{~�$��w|º|»�$x°t^{��4s�|}�^��t*zMs(�¼tZv(w�z�{¾½!¿°À�ÁÂ��$�$w��Z|»z�s�t��ÂÃÄz*|Å|=zM� z^�:�4{Æt��|��w��3z^x��zMs(�Ç��4�M�*��t�tZv(wBÈ�É�ÊÌËÍ�MÎ3ÉBÈÐÏ%É�Î� Ñ$�MÎ4Ò��*�M��v(�R|=w�

ÃBw|=z:�$w|Ó�$w�xVzMs(zMs(�Ô|=w��4{~��t�w¹��4v(z�s(w|Õt*�Ö��$�$w3�¯w4×$t*w4{Ps(��´|=w4{V�(z^��wØ��y��s(w�s�tV|º�uz�sÙtZv(zZ|{�w3xPzMs(w��w4s�tÚ|�t�w\� Û�w ��*|}� �$w�xPz�s(w t^v(w ��w3�4v(�4s(z*|��Ü| �$wR|=�4{�z��(zMs(� tZv(w Ý-Þ(ß!Ý�à�½�Þ�ß�Ý��y�á�$s(z^�3��t�z:��s��(w�tZÛ�w�w4s�t^v(w4�ãâP|=w�w;ä�z:��Á¨gå�æÐ

ç^è*ç*é*ê*ë�ìçZèVé*ê*ë�ìë�ì ç^èZç�é*ê*í*î ç^èZç�é*ê*ïIéðí

ç^èZç�é*ê*ñ:òIóõô ö ô ò�÷iô ÷iø

ç*èVé*ê*íZî ç^èPé*ê*ïIé�ííZî ïIé�í

ñMòIólô ö ô ò�÷gô ÷gøç^èCè^ê*ñ:òIóõô ö ô ò�÷õô ÷iøî�ùiö ú�û ÷gü�ý�óõú�û þIô ÿõú=ÿõò�÷ió��Pú�û

� � �

� � �ç*ï��ç^è*ç*é�êMç�ï��ç^èVé�êMç�ï��

� ��! ��"�$#�� &%(')'$%*�,+.-(/1032� ��,4'$5��-6��5%(798��,-*0: �;�<¿Æ�$�$w��:�^z�s(�²tZv(w��|}wy�$x�tZv(w��$z*|~tZ{�z��$��t�w��³|=w4{V�(z^��w��$zM{~w��t��{�zZ|Ç� ��{�w��y��:w4×0�ß�|º|ð�$��w�tZv(�\t�t^v(ww4×�w��4��t*z^��sáxP�:��Û¹�$x�|=w4{V�(z^��w��s(w4s�t��3�M�Z�M��Üz*|%��{~�4v(w|�t^{��t*w��?��tZÛ�� |=w�{P�(z^�3w£�$z�{�w��\t��{}|�=tZv(w�>@?�¶�A(È�É4ÊÌË�MÎ�ÉÌ¡y�IÊÌÉ�Î��^��Ê¼�4s(� È3«;È6B(È�É�ÊÌËÍ�MÎ3ÉÌ¡á�lÊ\É�Î��:��ÊR�¸-v(w?�4{~�4v(z�t*w��t^�${�w?�$z^��Í{��4� �$w��z:��t�z�s(�tZv(w;��(w4{��:��4{V{��4s(��w4��w4s�t¨z*|%|�v(��Û!s�z�s?ä�z^��Á¨DC�¸�v(w¼|}w4{P�(z:��wØw�×�w3�4��t�z:��sÖ��{��$�3w�w��(|1��{~�$zMs(�¼t��ãt^v(wØxV�$�^�:��Û�z�s(� |=�3w4s(�4{�z:�E=y�(z^� Ý-Þ�ß�Ý �$x��3�M�Z�M��I��F>@?�¶�A(È�É4ÊÌËÍ��Î�ÉÌ¡y�IÊ\É3Î��^��Ê�{�w��w3zM�(w|�tZv(w£{~w�G��(w|�t0t��?��{��(z^�$wÇtZv(wÇ��(|=zIt�z^��s(z�s(� |}w4{P�(z:��w�ß�x�t�w�{ tZv(w´{�wR|ð�(��tC|��$x�¡!¢�AHÉ3�*HJI��lÊLK¹�4s(�¼¥�¦MA$¦%�*HJI��lÊLK¹�4{�wÆ��t*��zMs(w3�(�N>@?�¶MA(È�É�ÊÌËÍ�MÎ3ÉÌ¡á�lÊ\É�Î��:��Ê{�w,G��(w|�tV|áÈ3«�È6A(È�É4ÊÌËÍ��Î�É³¡y�IÊ\É3Î��^��ÊÜt��Õw4×�w��t�w³tZv(wA{�w|�t��$x�tZv(w´|=w4{V�(z^��w �4s(� {�w�t^�${Ps t^v(w±{~w|ð�(�It�(��O��½��sÆ{�w3��w�zM�(z�s(� tZv(wÜ{�w|ð�(�ItV|yx�{��¤8z�t�xV��{PÛ��4{��(|�z�tBt��P>@?�¶MA(È�É4ÊºËÍ�MÎ�Éº¡á�lÊ\É�Î��:��ÊR�ä�zMs(�3�^��>@?�¶�A(È�É4ÊÌË�MÎ�É;¡á�lÊ\É�Î��:��Ê;{�w\tZ�${Ps�|�t��t^v(w�|=w�{P�(z^�3w��s�|ð�$� w4{�tZv(w£{~w|ð�(�It-�$x tZv(w£w4s�t*zM{�wÇ��(|=zIt�z^��s(z�s(�|=w4{V�(z^��wB�(z^�;Ý-Þ�ß�ÝÜ�$x��4�M�*��¸�v(z*|?��y��:w4×Æ�(w4v(�4�(z:��${��3�4s´�(wÜ��$t^�${�w��¯zMsÆ��s$�$�á�(w�{��$xÇ{~w�xPz�s(w4��w4s�t8|�t*w��H|�0ß£t;xPz�{}|�tC�-Û�w��|=w4{V�(wÆt^v(��t?È3«�È6A(È�É4ÊÌËÍ��Î�ÉÌ¡y�IÊ\É�Î3�^��Ê´��àV��{~�$zMs(��t*zMs(�Åw4×�w��4��t�z:��s �$x�§�©»¥)A$©¯É3Ò��"I�Ê\É,Q!É3��4s(�«SRõ�¨��Ê4��4T*QUA(V=�$ËR�$Î4Ò��*�M��²�3�4s��(w!��$�$w3�^�^w3��|��XW��:�4{��w�Y?|=w4{V�(z^��w!��y��s(w�s�t�§�©»¥[Zl«�§�¬ÓÛ!v(z:�4v��{��(z:�$w|ØtZv(w |=w4{P�(z:��w|¹§�©»¥)A$©¯É3Ò��I�ÊÌÉ,Q�É4��Å��s(�Ù«SRõ�¨��Ê��M�4T*QUA(V=�$Ë��$Î3Ò��*��¨´®1w ��|=wÙtZv(zZ|��|=w4{V�(��t�z:��s zMs ��${Bs(w4×$t�{~w�xPz�s(w4��w�s�tB|�t*w��0Hr*s±��${;��s�|=w�G��(w�s�t�{~w�xPz�s(w4��w4s�t�|�t*w��AÛ�wáxP�$��|£��s�$w��(|=z�t*z^��s²�$x�§�©»¥[Zl«�§�¬��¸-v(w!�$w��(|=z�t*z^��s²zZ|%��w4{~xP��{P� w��á�3��{��$z�s(��t*�?t^v(w8��{~��(|=w��|=�4v(w��w*= ��ãtZv(wµ{~w��4�${ð|=zM�(wØ��$��^z:��t�z:��s �$x°tZv(w¹��{~��(|=w�� |~��w��z^xVz^��\t�z^��s �4s(�Â{~w�xPz�s(w4��w�s�t��t:t�w4{Vs�|�â~|=w3w;ä�z^��Á¨D\�æ=ß�t�t^v(w��s�|=w,G��(w4s�t {~w�xPz�s(w4��w�s�t�|�t*w��H|�Û�w�xV�$�4��|��sy��4{Ct�z^��(�^�4{%|=w4{V�(z^��w£��s(w4s�tV|��4s(��{~w�xPz�s(wtZv(w��ÔâCzMsát^v(w£Û��á�$w|=�4{~zM�(w�� (��(w3æ��$s�t*z^�HtZv(w!�$w|=zM{~w��á�:w4�(w��$x��{��s$�(�^�4{~z�t^�yzZ|��t*��zMs(w3�H*]Çs(��w��:� w4×$t�w�{Ps(��¼|=w4{P�(z:��w ��s(w4s�tV| �4{�w z�s ��^��3w�ÅÛ�w ��4s x��${VtZv(w�{ �$w��3��y��(|=w tZv(w�z�{|��w��3z^xPz:��t*z^��s�|±��¹|=w��4{~��t�z�s(�£tZv(w3zM{�«£¶�© �4s(��«£¶�«�©Ô��4{CtV|��Þ��(�4v��$w��3��y��(|=zIt�z^��s�Û�z^�:��:�^��Û

14

^5_ âàb4cLd^L_aàb�cLd^5_ âàb�e4f�gDh i h f�j�h jDke4fDgDh i h f�j�h jDk^5_L_�b4e�f�gDh i h f�j�h jlk

mon�i p�q j�r�stglp�q uoh vlp!vlf�jDgDw�x!p�q

ycLd zLm ^5_ âàb�zLm { `!z | ^ {�}�~^5_ âàb { `!z�bo^ {�}�~^5_aàb4zLm ^5_aàb { `!z�b�^ {D}�~

{ `!z ^ {�}�~^L_ ^Làb { `!z ^L_ âàb�^ {D}�~^5_aàb { `!z ^L_aàbo^ {�}�~

��5��X��,�E�4�$��,�&�(�)�!�*�,��(��,�,� �$� ��6�$� �(�9��*�:�N�*��1��L�F ��6¡J �¢�¡(� £!¤"�L¢X�6¡¥�5¦J¢X ,�6§¨§¨�*¡J©4 �¤"�L© �6¡J¤�ª¬«�¤�£��®�*¯�� ¦J¢�£!¢°�$«�¢� "�a©�±J¢² ��6§³«��6¡J¢�¡(��N¤�¡J´¥¯a�*£��5¦J¢"££!¢,¯�©�¡J¢N�5¦J¢�§¶µ(·�©�¡(�5£!�*´6�J ,©�¡J¸X´*¢"�L¤�© ª5�¹�*¯�£$¢�º6�J©�£$¢�´� ��6¡J �£$¢"�a¢U ��6§¨§»�*¡J© �¤"�L© �6¡X«�£$��a�* ��*ª5�"¼½ ¦J¢®§F�6£$¢&´*¢"�L¤�© ª4¢�´�´*¢°�� £$©�«*�L© �6¡³�*¯E� ¦J¢¾«�£!��«��J�¿¢�´�¤"«*«�£!�*¤, �¦³ �¤�¡�µJ¢&¯��6�*¡J´�©�¡�À4Á¬¼tÂ�Ã�Á¬¼�Ä6Å�¼

Æ¹Ç4È@Ç¬ÉËÊ1ÌÎÍ�Ï[ÐÒÑ�Ó*Ô�ÑÕÍMÓ(Ð½ ¦J¢&´*¢�§¥�6¡1�!�5£$¤"�a�6£Ö�¹¯��6£��5¦J©L�M �¤°��¢×�$�5�J´�·�ØX©4ª ª1©�¡J �ª��J´*¢(ÙÚ ¼Û�5¦J¢Ë ��*ª4ª ¢� Ü�a© �6¡Û�*¯�¯��6£�§F¤�ª&ÝÞ§F�*´*¢�ª5�Fß$�!«�¢� ,© ¯�©4 �¤"�L© �6¡1�¿àá´*¢°�¿ �£!©�µJ©�¡J¸â�!«�¢� ,© ¯�©4 �¤"�L© �6¡ã¤�¡J´

´*¢�±J¢�ª4��«�§F¢�¡(��«�¤"� �L¢�£�¡1�M¯��6£��L¢�ª ¢, ��6§¨§»�*¡J© �¤"�L© �6¡¨�!·��!�L¢�§9�:ÃÁ¬¼Û«�£!��L�� ·ä«�¢°�®�*¯@�5¦J¢å�L�*�*ªL�&�Ö�(«*«��6£�a©�¡J¸¥¤��(�a�6§¥¤"�a©4 å�5£$¤�¡1��ª4¤"�a©4�6¡9�*¯��5¦J¢�æ�·6£$¤�ç�èéæ)ÁJêaµJ¤Ò��¢�´

´*¢�±J¢�ª4��«�§F¢�¡(��«�£!�* �¢Ò�:�¹©�¡(�L�³�!«�¢� �©4¯�©4 �¤"�a©4�6¡³¤�¡J´²£!¢,¯�©�¡J¢"§F¢�¡(��«�£!�* �¢°�3�¹�*¯E� ¦J¢UÝëèì¢"�5¦J�*´JÃíÒî ¤¾«�£$��a�� ·ä«�¢&�*¯¬�5¦J¢®§¥�*´*¢�ª5êLµJ¤°��¢�´��L¢°�!�a©�¡J¸å«�ª��J¸(ê�©�¡E¼

Æ¹Ç4ï@ÇEð²ñ¹Ñ"ñNÓ(ÊFÉPÊ(ò¹ÊJó�Í@ô�ÌõÊ1Ï¹Ñ&Í�öUÑ"÷[Ê�ø�Ô)Ð°Ê.ùMÑ"ñ[úMû½ ¦J¢&¯�(� �*£!¢®Ø²�6£�ü³�6¡X� ¦J¢& �¤°�¿¢×�!�5�J´�·�Ø²© ª ª*«�£!�* �¢,¢�´�¤�ª �6¡J¸×�5¦J¢&¯��*ª ª �6Ø²©�¡J¸²´*©�£!¢, "�a©4�6¡1�,Ù

ý þ ¢�±J¢�ª ��«�§¥¢�¡(�ÿ�*¯ÿ� ¦J¢ §F¢"� ¦J�*´*�*ª �*¸ä· ¯��6£é£$¢�¤°��6¡J©�¡J¸ ¤�µJ�6�(�ÿ¯�¤��Jª�� L�*ª ¢�£$¤�¡J �¢ ©�¡ � ¦J¢¯��6£�§F¤�ª4©L��¢,´Xæ�·6£$¤&´*¢�±J¢�ª4��«�§F¢�¡(��«�£!�* �¢Ò�:�:Ã

ý þ ¢�¯�©�¡J©��a©4�6¡ �*¯)«�£!¢� �©5��¢å£��Jª ¢°�N¯��6£��5£$¤�¡1��ª ¤Ü�a©�¡J¸��5¦J¢Sç²è æ)ÁJêaµJ¤°�¿¢�´»æ�·�£!¤å´*¢�±J¢�ª4��«�§F¢�¡(� ©�¡(�a�ÝUÃ

ý � ¡(�a¢�¸ä£!¤"�L© �6¡ �*¯X§F�*´*¢,ª5ê� "¦J¢� �üJ©�¡J¸â©�¡(�L�â£$¢�¯�©�¡J¢�§F¢�¡(�×«�£$�* �¢°�:�»�a�ã¤�´*´6£!¢°�3�¥§¥�*´*¢�ª ª4©�¡J¸â�*¯¡J¢"� ØX�6£�üX«�£!��a�* ,�*ª5ê$�$«�¢� �© ¯�© & ,�6§¨§¨�*¡J©4 �¤"�L© �6¡1Ã

ý èì�*´*¢�ª4ª ©�¡J¸X�*¯E«�¤�£$¤�ª ª4¢�ª ©5�Ö§ ©�¡X�5¦J¢&¯��6£�§¥¤�ª ©5��¢�´Xæ�·�£!¤&´*¢"±J¢�ª ��«�§¥¢�¡(��Ãý � ¡*¦J¤�¡J �©�¡J¸��5¦J¢¨§F�*´*¢,ª5êaµJ¤Ò��¢�´.�a¢°�$�a©�¡J¸.§¥¢"�5¦J�*´*�*ª4�*¸ä·Ë©�¡ÿæ�·6£$¤»�a�*¸(¢Ü�5¦J¢�£&Ø²©�� ¦P�5¦J¢¨Ø²�6£�ü

�6¡X�5¦J¢¾§F�*´*¢�ª êaµJ¤°��¢,´��a¢°�!�L©�¡J¸å«�ª��J¸*ê�©�¡1Ãý � �(�a�6§F¤Ü�a© N�5£!¤"¡1��ª ¤"�L© �6¡³�*¯F�5¦J¢Uæ�·�£!¤¾ç²èéæ ÁX§F�*´*¢�ª5�¹©�¡(�L�XÝë�1�¿©�¡J¸å� ¦J¢®ç²Á*Ýé�L�*�*ª�¼

½ ¦J¢ §F¢"� ¦J�*´*�*ª �*¸ä·â¯��6£�£!¢�¤Ò��6¡J©�¡J¸ë¤�µJ�6�(��¯�¤��Jª��S�L�*ª ¢�£$¤�¡J �¢ ØX©4ª ªUµJ¢Ë´*¢�±J¢�ª4��«�¢�´éµ(·ë©�¡(�a¢�¸�£$¤"�a©�¡J¸§F�6£$¢ £$¢�¤�ª4©L�!�L© ¯�¤��Jªo� �L�*ª ¢�£$¤�¡J �¢ §F¢� "¦J¤�¡J©L�Ö§ � ß�¢6¼l¸1¼�Ãì´*© ¯�¯�¢�£$¢�¡(�õ� ·ä«�¢°� �*¯ ¯�¤"�Jª�� £!¢, ��6±J¢�£�·«�£!�* ,¢�´6�*£!¢°�Öà��1��¢�´�©�¡X�5¦J¢¾«�£$¤� "�L© �¢&�*¯¬�a¢�ª4¢� ��6§»§¨�*¡J© ,¤"�a©4�6¡¨�!·J�$�a¢�§ �"¼� ¢ã¦J¤�±J¢Û¤�ª�£$¢�¤�´�· ´*¢�±J¢�ª ��«�¢,´ ¸(¢�¡J¢�£$¤�ª¨¸��J©4´*¢�ª ©�¡J¢°� ¯��6£��5£$¤�¡1��ª4¤"�a©�¡J¸ �5¦J¢ãç�èéæ)ÁJêLµJ¤°��¢�´ æ�·6£$¤§F�*´*¢,ªL�¾©�¡(�a�¨Ý �$«�¢� �© ¯�© �¤Ü�a© �6¡1�Ü¼ ½ �»§F¤�üJ¢�¤��(�a�6§¥¤"�a©4 S� £!¤�¡1�¿ª ¤"�L© �6¡F�*¯ � ¦J¢åæ�·�£!¤S§F�*´*¢,ªL�¹«��J�:��©�µJª4¢°Ã

15

�� ! "�� #��%$��'&��(��! )��*+,�'-'�� .�-/�0��1 �*2�0��$��3��-'�%�! 54��'�3�6�'&��7��3��8 9��:;=<?>A@ $��07��/��2B, ,*2�'-'��:C��-57D��$��'&� E�3��$=��)-/�0��1 �*2�0��$�� FG �*2�/-'��:C��-'��0�H �I

J ��3��K*2&%�3�� L��M:8��C��3N$��3O��/&��#*M��P �*2�/-'��:C��-'��0�Q�3��$R��/:��7��3��S*2�T��U��H V7��$��/&�&��(�� *2�3,�'&�&%�'&M�3W2�'-3��U�%�0�X��:Y-'�07K7��%-'��U�(�� Z "�3�O��%-'�[-'�07K*2�0��C �I J �[�3��O�� "�/ ��\��Q:C�0�7��/&7��$��/&�&��(�� ]��:)$�� ,��(4��U�%�0�^��:_*2�3��'&%&��'&E4��3��3O��0��`�0O��39�� 0��O��3�M��a�0Cb^��-3��c�U�'-��&%&4��)�3��1 �*2�'-'�%�'&�&cde-3��/&�&�� V*+,�04�&��376I

f �L��K-3,�'��'$] �*2�/-'��:C��-'��0�P*2��3��R��:g�-'�07K7��-/��U�(�� P-/�07K*2�0��3��h��a��3O��$��'&��(4��3��'&(d �*2�'-/��:��%�'$R��-'�07�7K��-'�T�U��0��/&E*2�3C�SO��3Cd]�34H ��,�'-��&(dHIjiA�� '&�&%�0�� V�H N��k�(�H ��U��U��T�U��(�S�a�c��O��8��'&%&(dl��dl-'�07�7K��-'�T�U��0�m*+��#��-'��&CInih�o-��'-3bG$#d0��37D��-6*+��#*2��C�U�%�! D�! K�a�/&�&`�! K��/�! "�0��34��0��:��&(��U��&%�3��3��-/�o�3��$p*2�3��/&�&��/&�� 7 �(�q*+,�#�U��-'��&�-'�07K7��-/��U�%�0�Hr`��m��&%&�(��O��! �� *�*2&%��-'��0��:s7��$��'&2-3��'-3b��(�� V�U�'-��t0��! �I

u ��/&�&(d+rj�=��%&��$��3O��/&��#*2�� L��7��$��'&�BU4��! .�'$6�U�! �� L*2&(�� BC�(�Hrv��a�%&�&n�3W�*2&��0��0�w��6�H "��$��3O��/&��#*2�'$MFx7D��$��'&� a��:`-'�07K7��-/��U�(�� ^ ,d� ��37P a�! a�3�Q�'$�$��c�U�%�0��'&_ "�0��,-'�K��_-'�3�M4��H "�'$e:C�0j��! ��s 0�3��3��T�U��0�sI

ynz%{|z~}M�+��H��2��

�+�%��c�1�1�C�'��#��5��#��c�'�!�V��1��s�1�0��C�'�!�V��!�¡ U�'�n¢E�'�`�0�c�¤£L¥/¦��U��a�n§��n�S�_¨(©Nª8«��5�/��¬��1��(�'��! H®Q�1�U¯#«/¨,¥#°�±3² ³2´+�Cµ��V�¤¶)�'�U¯9·+�C�!�/�Cµ��`�V��«/·+�C�1�#�0��µ��/©N�+�'¸��!��¸'¹!¹º«3»g�º��(�#�#¼!¼'½��

�+� �+��n�S�g¨c©x�5�3�(�¾�#��Cµ�¿0�c�V�g½aÀL°~��µT¬T�Tµ�¿��c�N��TÁ'�0��V��1�U�S�5�!¬��!�V��1�h U�'��¢hµ/��¥1��0Âº�c�/�,«2·��C��Ã"��¬¤�¨,¥#°�Ä8¸��º�!��¸/¹!¹#«/´2��¿!�8�#µ��¦V�#¼!¼#¸0�

�+� Å��Æ�� Ä%�g��»g¿º��cµ��!ÇºÈºÉ|Ê|Ë�Ê|ÌºÌ'Íº��¢hµ��`¿!��cÂ!�1�EÎg��¾�#��,��¦`·��C�/�Ï�,«��"¹!¹º±��+� ½+��ÐE� Ðjµ��¿��0�%�,«��E� °s�C�'�!¿��¾�U��¦#�#µ3«¡¥�� Ðj��!�#Ñ��#��0«�Æ3� ÐA�(�(��«~µ��#ÂDÒ`� Ó6µ��¯+��´2�'�8�Vµ��|¥0��0�c¬T��Ä��c��1��TÂ

�5�¤�#�3�c�'�!�V��!�Y�! l´2µ��¾�Y°j�º�c��µ��1�m¢h�'�`�`�!�0�(¬Tµ¤��0�X¥/¦��U��a�"��¨��w·+�C�º¬1��h�s´2°nÔc�#¼!¼#¸[ÀÕ Ì'ÖÏÍT×"ÈºÌCØÙÌ'ÚDÛnÜ Ý+Ì'Ö"Ì!Þ'×`ß¡Ú3Ý�ÜàÚ#ÉTÉ�ÖTÜàÚ3ÝkÌ%áâAãºÞºä(å�Ç#Ìºä(É�Ö.ã1Ú0åAæ¤ç0×�å(É�èS×�«2©N�¤¶)¬Tµ/�U��(�a�!�#�'�6°2¦#�#��«°��¬�é!�0�c¬�µ��º�n��#�'�U�+�º +Î5�0�¾�#��¾��¦=�! �©N�¤¶9¬Tµ'�U��c��«/Îgê)«'Æ.�0�ë¦V�#¼!¼#¸0�

�+�à¸#��ÐE� Ðjµ��¿��0�%�,«)�E� °s�C�'�!¿��¾�U��¦#�#µ3«�¥�� Ðj��!�#Ñ��#��0«)Æ3� ÐA�(�(��«`µ��#ÂGÒ`� Ó6µ��(��¯+�S´2�'�U�Vµ��NÓ6�ºÂ!��cÄ%�_��#��5�¤�#�3�c�'�!�V��!� �! ¢h�1�`�`�!�0�c¬Tµ��#� ¥/¦��U��a�"�ì°~Î9¢S¥ °j�T¬�é!�0�(¬Tµ�� n��0�'��« �#¼!¼#¸#�é1�(�%�2í î(î(¶g¶_¶=� ��#¬/�"� 8�¾î%�C�/��Tµ��C¬�é1îU�,��c�/�8îU��(�1� �ºé!�0ï"��¦#�0��ð��¬�é!�C��0�'��ñg¦��µ��8ð��0¼!¼#¸

�+�ò±��,¥�� Ðj��!�0Ñ��#��0«1ÓQ� °~�!�8�!�#��0«ºµ��#Â9¨�� g�(�¾�#��"�,ó+Ø!Ø|ä�Ü¾ôTãºå�ÜÌ'Úgõ9Ö�Ü¾ö3É�Ú_÷PÉTåcÈ#Ì'ø#Ì!ä(Ì�ÝTç~á1Ì'Ö�õ`É�ö�É�ä(ÌCØ¡ègÉ�Ú#åÌ�áQù|Ì1è_ègÞ1Ú�Ü¾ôTãºå�ÜàÚ3Ý?æ�ç0×¤å(É�è�×3�¡´+�_ÐnÔ�¼1½#«E´2�'�U�!�ú�'�l¥!�0�T¬��c 8�(¬Tµ¤��c�1�^µ��#ÂM�5�/�,�(�/�kÐjµ��0�/�#µT�1�/�"�Ð¡�(��c��«/´+��µ��#¬T��«�¥#��1��`¿#��~�#¼!¼'½��

�+�òû��U¢��¾¥!�#�!�1¯9µ��#ÂgÓQ� üh�1��c��.��ýsþ'ÊKÿSóMå�Ì!Ì!ä�á1Ì'Ö|å�Ö.ã1Ú1×�äcãºå�ÜàÚ/Ý�ý2÷��~Ë�ÊPègÌ'ø#É�ä×nÜ¾Ú#å(ÌSÊh«1��gÓR��U�V�¤��«�Æ3� «�jÂ0�¤�nýH÷��~Ë�Êvæ�ØAÉ�ô1Ü á#Ü¾ôTã#å�ÜÌ'Ú�á1Ì'Ö��AÖ"Ì1ö�É�Ú�ßAè��!É�ø!ø#É�øPæ¤ç0×¤å(ÉTèS×)õ`É¤×�Ü Ý�Ú0«j¬�é#µ��!��9±��j¥!�!�,��#�1��«�#¼!¼1½+�

�+��º�UÅS·�·��3°j�T¬�é!�0�(¬Tµ��8�#��¬��c 8�c¬�µ¤��c�'�N��¸#� Å#¼#¸0í0¥1��µ��1�n�` ��º�#¬¤��c�1�#µ��+�8�#�T¬3�c 8�c¬Tµ��c�'�N�! �Îg�D�#�0��¾��c�'��#��9Î9°s�|»�©e�1¥0�T�né1�(��2í î(î(¶_¶_¶�� Å!�/�º�� 1�C�3î� ��!î8¥!�#�T¬'�Uî�é1��=�(Ä��# U�/î%��¸/Åº¼#¸#� é1��

�+� ¹��UÅS·�·��|°��T¬�éº�0�c¬Tµ��)�8�#�T¬3�c 8�c¬Tµ��c�'�^��¸#� ½�¸/Å+í¡Î)°~�|»�©X¨��º�#¬P��1��C UµT¬��D�#�0�,��c�'�0��#�]¬Tµ��c¬��0�cµ¤��(�'�µ��!��(�c¬Tµ¤��c�'� �0µ�� §��0¬Tµ��#ª ��c�/�#µ��(��#�� ¥#�T� é1��2í î(î�¶_¶_¶=� Å!�/�!�� '�C�3î� ��1î8¥º�#�T¬/�Uî%é1��=�cÄ��# 8�/î%��¸3½�¸/Å�� é1��

16

SECTION 3. INITIAL REPORT ON CASE STUDY DEVELOPMENTS FOR CASE STUDY 2: ENGINE FAILURE

MANAGEMENT SYSTEM

3.1. Introduction This section of the D8 report summarises the developments in AT Engine Controls (ATEC)α case study “Engine Failure Management System” as part of the RODIN project. It also discusses how the development of the case study will provide some tangible demonstration that can be used to evaluate the impact of RODIN on Engine Failure Management. The work on the case study has addressed the following tasks from the Description of Work [3.10]. T1.2.1 Define case study, evaluation plan, measurements and assessment criteria T1.2.2 Produce an informal specification of a typical engine failure management system T1.2.3 Use the informal specification to produce a visual formal specification Contributions have been made to other tasks and are commented on later. The work has been presented to the RODIN project in a series of internal workshops and presentations outlined below. Initial RODIN presentation (University of Newcastle September 2004)

This outlined issues on the case study which are to be addressed by RODIN. This included a feasibility study into abstraction of failure management using UML-B. From this presentation work continued in developing a natural language description of the case study to prepare for the next workshop.

Requirements workshop (Chilworth December 2004)

It provided an introduction to learning the methodology of “Event B” for modelling and a methodology to specify a traceable requirements specification presented by J- R Abrial by means of an example structure requirements document [3.12] This led us into work into requirement research and its development on the Traceable Requirement Specification.

α “AT Engine Controls” was formerly called “VT Engine Controls” (VTEC) which was the name referenced in previous RODIN deliverables.

17

Presentation on work (Helsinki workshop, March 2005) A summary of the case study development was presented including some

early work on requirement engineering and model development. The following deliverables and papers have been generated from the Case Study work so far. RODIN deliverables of case study D2 (D1.1) Definition and Evaluation Plan [3.6] November 2004 D4 (D1.2) Traceable Requirements Specification [3.7] February 2005 D8 (D1.3) Interim report (this report) Papers

1. “Rigorous development of reusable domain specific components for complex applications.” [3.1] (This paper provided exploratory modelling of the domain).

2. “The engineering of generic requirements for failure management” [3.2]

3. “Towards a methodology for rigorous development of generic requirement patterns”[3.3]

18

3.1.1. Case Study Development The definition of the engine failure management system as a subsystem has been described in the deliverable of D2 [3.6] and in the initial presentation of the project. The context of the subsystem is shown in Fig 3.1 below. It illustrates that all the sensor inputs to the control subsystem are handled by the Failure Management Subsystem. The subsystem processes these inputs to provide a managed input to the Control Subsystem which in turn drives the engine.

Figure 3.1 – Environment of Failure Management Subsystem Principally ATECs’ aim is to improve an Engine Failure Management Systems’ maintenance and re-use, by adopting RODIN methods. The use of the technology is expected to contribute to improvement by

1. Being able to accurately model the domain in order to reduce the semantic gap between application requirement and system design.

2. Promoting re-usability by being able to develop a configurable generic

specification.

The application domain is safety critical which makes RODIN rigorous methods a particularly attractive solution for AT Engine Controls.

AT Engine Controls intention is that the development of these models will form the basis towards design and implementation of a future system.

19

AT Engine Controls have been working closely with the University of Southampton who have provided the necessary support and education in developing a solution using a UML_B approach [3.4]. 3.1.2. Case Study Development Cycle The intention was to develop the modelling into two phases. The development phases are described in deliverable D2 [3.7]. The first phase was to establish the modelling of a representative system using RODIN methods (aim 1). The second phase was to consider more generic functional and component requirements in order to provide re-configurability and reuse (aim 2). However during the course of development the boundaries of these phases have become less distinct. The creation of a typical requirement specification has resulted in a generic specification. Furthermore the modelling of this general system has identified common components within the system appropriate to generic modelling. In essence some of the work intended for Phase 2 is being addressed in Phase 1. The current intention is to complete the existing model for this phase and then evaluate its generic aspects before entering into the next phase. The generic model is intended to be converted to the new version of the UML_B toolset in Phase 2.

3.1.3. Informal Requirements Stage A representative requirement of an engine failure management subsystem was produced in natural language format. The approach taken was for a domain expert to identify the functional requirements common to different engine failure subsystems in order to form a representative engine failure system specification. Some anticipation of future requirements were also incorporated. This resulted in a specification for a general engine failure management subsystem. The specification described the general functionality supported by detailed instances which were held in tabular form. It supports the idea of a table being used to validate a variant in a generic model. This contributed toward the development of a more generic specification which was developed further in the traceable requirements specification.

3.1.4. Traceable Requirements Specification The specification is described in detail in deliverable D4 [3.7]. It was generated adopting the format guidance presented in the internal RODIN Requirements workshop Chilworth (referenced in the introduction). Its salient features are:-

• A more rigorous natural language definition of generic requirement with

traceable reference to the instance data. (This was supported by explanatory text).

• A more rigorous database style definition of the tabular data.

20

• A taxonomy which identifies the requirement entities of the domain.

• A first cut diagrammatic entity relation model which defines the

relationships between these entities.

The approach adopted from the workshop worked well in presenting the requirement, the adoption of the taxonomy was particular suited to labelling common components appropriate to generic design. However it was felt that more research was required in support of developing generic requirements. This led to an investigation into research into domain analysis and domain engineering. The investigation identified the concept of product line engineering and how it might be applicable to the failure management domain. The Production Line concept [3.2] nurtures the idea that a template can be used to generate a family of variants of failure detection management systems, this is suited towards developing a generic requirements model for reuse. Some work on domain analysis and engineering is outlined below and described in more detail in Snook et al [3.2]. It supports ATECs’ aim of reusability of an Engine Failure Management System.

3.1.5. Domain Analysis A core set of requirements were identified from the representative failure management engine system. For example, the identification of magnitude tests with variable limits and associated conditions established several magnitude test types. These types have been further subsumed into a general detection type. This type structure provided the taxonomy for classification of the requirements. Domain analysis showed that failure management systems are also characterised by a high degree of fairly simple similar units made complex by a large number of minor variations and interdependencies. The domain presents opportunities for a high degree of reuse within a single product as well as between products. For example, a magnitude test is usually required in a number of instances in a particular system. The domain contains a few simple units which are reused many times. A particular configuration depends on the relationships between the instances of these simple units. A first-cut entity relationship model was constructed from the units identified during this stage. The entities identified during domain analysis were:

• INP Identification of an input to be tested. • COND Condition under which a test is performed or an action is taken. (A predicate based on the values and/or failure states of other inputs). • DET Detection of a failure state. A predicate that compares the value of an expression to be tested against a limit value. • CONF Confirmation of a failure state. An iterative algorithm performed for each invocation of a detection, used to establish whether a detected failure state is genuine or transitory.

21

• ACT Action taken either normally or in response to a failure, possibly subject to a condition. Assigns the value of an expression, which may involve inputs and/or other output values, to an output. • OUT Identification of an output to be used by an action.

Domain analysis also described the concept of requirement rationale. Considering the rationale behind a requirement is useful in reasoning about requirements in the domain. For example, the rationale for confirming a failure before taking action is that the system should not be susceptible to spurious interference on its inputs. From the consideration of requirements rationale, key issues were identified which served as higher level properties required of the system. An example of such a property would be that the failure management system must not be held in a transient action state indefinitely. The rationale from which it has been derived is that a transient state is temporary and actions associated with this state may only be valid for a limited time. It is felt that the consideration of such rationale and key issues will form an abstract model which is refined by the generic requirement model. 3.1.6. Domain Engineering The aim of the domain engineering stage is to explore, develop and validate the first-cut generic model of the requirements into a validated generic model. At this stage this is essentially an entity relationship model, omitting any dynamic features (except temporary ones added for validation purposes).The UML_B approach adopted for the case study and the supporting tools are described and referenced in the next section 3.2. The first-cut model from the domain analysis stage was converted to the UML-B notation by adding stereotypes and UML-B clauses (tagged values) as defined in the UML-B profile [3.11]. This allows the model to be converted into the B notation where validation and verification tools are available. The model contains invariant properties, which constrain the associations, and ensures that every instance is a member of its class. To validate the model we needed to be able to build up the instances it holds in steps. For this stage a constructor was added to each class so that the model could be populated with instances. The constructor was defined to set any associations belonging to that class according to values supplied as parameters.

OUT

CONDDET

10..*

+dcond

10..*

ACT

1

1..*

+aOut1

1..*

1

0..*

+aCond 1

0..*

INP

CONF

1

1..*

1

+dets 1..*

1..*0..* +tAct 1..*0..*

0..*0..*

+pAct

0..*0..*

0..*0..*+hAct

0..*0..*

1

1

+input1

1

Fig. 3.2. Final UML-B version of generic model of requirements

22

The model was tested by adding example instances using the animation facility of the ProB model checker (see section 3.2) and examining the values of the B variables representing the classes and associations in the model to see that they developed as expected. The model was re-arranged substantially during this phase as the animation revealed problems. Once we were satisfied that the model was suitable, we removed the constructor operations to simplify the corresponding B model for the next stage. The final version of the UML_B model described above is illustrated in fig 3.2. A detailed description is provided in the generic requirement paper [3.2]. 3.1.7. Requirements for a Specific Application Having arrived at a useful model we then use it to specify the requirements for a particular application by populating it with class instances. We use the verification tool ProB to check the application is consistent with the properties expressed in the generic model. This verification is a similar process to the previous validation but the focus is on possible errors in the instantiation rather than in the model. Although our example is small compared to a real application, there is still a substantial amount of data entry involved and errors were expected. The technique was found to be highly effective, detecting all the data entry errors and satisfying the invariant within a few iterations. 3.1.8. Future Development The next stage is to add behaviour to the generic model by giving the classes operations. In future work we will investigate the best way to introduce this behaviour during the process. It may be possible to add the behaviour after the static model has been validated as described above. Alternatively, perhaps the behaviour will affect the static structure and should be added earlier. In either case, we aim to formalise the rationale described in the domain analysis and derive the behaviour as a refinement from this.

3.2. Directions on RODIN Methodology and Tools In order to meet the RODIN objectives the case study is seen to be a driver on RODIN methodology and tools. The following outlines the contribution of the case study to these areas. The next section outlines the experiences with the technology.

3.2.1. Methodology The case study is intended to drive the methodology by presenting issues and experiences from the problem domain. The adopted methodological approach being used by the case study is modelling using a UML-B approach [3.11]. The experience of developing a generic model described in Snook et al [3.1, 3.2, 3.3] is likely to be the main consideration which will contribute to the RODIN methodology. The impact on methodology is to be described in the methodology deliverable D9 [3.8]. Some experiences using this methodology are outlined in the next section.

23

3.2.2. Plug-in Tools The case study is intended to drive the development of plug-in tools by providing some feedback of its experience of using them when applying the methodology. This case study uses plug-ins which support the UML-B approach. However the new Plug-in tools intended for this approach have not been made available at this point (in development for the eclipse platform) this has forced the case study to work with some older existing tools that were available. The tools used by the case study in the UML_B formal development are U2B and ProB. The UML-B [3.11] is a profile of UML that defines a formal modelling notation. UML-B consists of class diagrams with attached statecharts, and an integrated constraint and action language based on the B AMN notation. It is suitable for translation into, the B language. The U2B [3.5] translator converts UML-B models into B components (abstract machines and their refinements), thus enabling B verification and validation technology to be exploited. U2B has been implemented using Rationale Rose s’ extensibility features this is expected to change to a different implementation in future tool development. Experience with this version of the UML_B profile may identify areas of improvement in terms of representation ability and ease of use which can be applied to the new tool development. ProB is a model checker [3.2] and has been used to provide verification and through validation via animation of models developed during the case study. Verification of the requirement serves to strengthen the mapping of the model to the requirement specification. Verification provides confidence that the UML_B model represents the requirement accurately. It is the closeness of mapping in conjunction with the understandability of the model which will help to reduce the semantic gap (aim1). However the validation of the requirement is particular useful for AT Engine Controls as this allows early exploration of the requirements which can identify unintended behaviour or incomplete requirements which can help improve the dependability of a system and potentially and development cost savings. The case study is expected to contribute to development of the U2B and ProB tools in terms of how effectiveness and its ease of use for the novice. Finally in addition to the profile and tools described above it is anticipated that development of the case study will identify new areas of tool support. Some areas have already been identified in the following section.

3.3. Results and Experiences of the Technology Whilst it is still too early in the project to provide significant evidence to support evaluation, the experience of using the technology so far is summarised below.

24

3.3.1. Modelling The stage of development that the model has reached has been described above. The progress is considered to be good by ATEC as the static model developed is already starting to addresses their aims in the case study. The semantic gap is being reduced as illustrated by the closeness of mapping between the requirements specification and the model components. This was also verified with an instance model. Reusability is being addressed as the static structure has identified generic components which have been verified against the instance model. However the model still lacks behaviour and scaleability is yet to be tested. Furthermore exploratory modelling of behaviour has already identified weaknesses in the requirement. Snook et al [3.1] identified that a state can exist where a common transient action such as a freeze can be maintained for a longer period if the individual inputs that share this action fail after each other. Similarly if a given test input is failing erratically then its transient action can persist. These results provided an early indication that a rigorous approach provides quality benefits. 3.3.2. Learning the Technology The learning of the RODIN technology for AT Engine Controls has been addressed through the RODIN workshops and working with the University of Southampton. The following specific areas have been targeted. UML_B method

UML_B tools Formal methods Modelling The learning and applying of a developing technology alongside research activities has presented particular challenges to the novice learner which are summarised below.

1. Mastering the concept of modelling rather than implementation 2. New toolset availability 3. Existing tool functionality limited eg lack of bi-direction relations, unclear

error messages 4. Limited UML_B examples to learn from. 5. A comprehensive understanding of formal notation is required to support the

UML_B method. ie how to express behavioural concepts in its notation 6. Time/resource available to learning to be shared with research activity 7. Establishing a foundation knowledge in formal methods alongside the

UML_B method. 8. Developing the case study model in parallel with learning technology

concepts.

25

Model development of the case study has also identified weaknesses in the existing tools which has identified areas potential areas for new tool development. 3.3.3. Experiences with the tools UML_B profile The following improvements were identified using the current profile implementation.

• Ability to make more information visible on diagrams - this will assist in making the model more readily understandable.

• Bi directional associations should be better supported (in the current U2B tool they are translated but navigation in uB is sometimes difficult depending on multiplicities – this should increase both understanding and efficiency in generating models.

• Some restriction to prevent only correct UML_B constructs from being specified would be useful. It was found that incorrect code could be entered which could cause problems when running the ProB tool.

U2B tool This tool is easy to use. One problem was that the conversion into B was not always successful eg the $ operator being ignored. This bug was corrected in U2B. Pro B The tool was successfully used to animate and model check the model. ProB provides an indicator to show when the invariant is violated. Due to the ‘required’ (i.e. multiplicity greater than 0) constraints in our generic model, the only way to populate it without violating the invariant would be to add instances of several classes simultaneously. However, we found that observing the invariant violations was a useful part of the feedback during validation of the model. Knowing that the model recognises inconsistent states, is just as important as knowing that it accepts consistent ones. We found that the analyse invariant facility provided useful indication of where the invariant was violated (i.e. which conjunct) but, in a data intensive model, it is still not easy to see which part of the data is at fault. This is another area for tool improvement. 3.3.4. New Tool Support Experience of modelling has shown that the size of a failure management requirement can create practical difficulties with the amount of data that has to be input. This became evident when only a few instances were tried when populating the static structure of the model. A requirements manager plug-in tool is envisaged to assist with this problem.

3.4. Demonstrators and Evaluation The evaluation plan D2 [3.6] has identified three parallel purposes of the case study. These are summarised as

26

a) to evaluate the UML_B method from AT Engine Controls viewpoint b) to improve the maintainability and portability of failure management software c) to provide feedback to the developers of UML-B. The evaluation of these have been defined by goals and metrics described in the plan. The application of these goals and metrics are ongoing throughout the project and are expected to come to completion in the final report. The interim reporting of metrics will be limited to what can be demonstrated at particular points. In phase 1 the intention is to demonstrate a verified and validated visual model of the failure management system. In phase 2 the intention is to demonstrate a generic system from which variants can be derived and techniques explored and the development of the model to a package explored. This report has provided some qualitative feedback of the progress so far. An attempt at ranking the evaluation criteria at this point has been given in the deliverable D14 [3.9]. The metrics being collected are

- time spent learning the technology - problems identified in learning ( see above section) - defects being found in the model/requirements (verification and validation) - time spent developing models - improvements identified in tools

3.5. References

[3.1] C. Snook, M. Butler, A. Edmunds, and I. Johnson. Rigorous development of reusable, domain-specific components, for complex applications. In J. Jurgens and R. France, editors, Proc. 3rd Intl. Workshop on Critical Systems Development with UML, pages 115–129, Lisbon, 2004.

[3.2] C. Snook, M. Poppleton, and I. Johnson. The engineering of generic

requirements for failure management Accepted for Eleventh International Workshop on Requirements Engineering: Foundation for Software Quality, REFSQ'05, Oporto, 2005

[3.3] C. Snook, M. Poppleton, and I. Johnson. Towards a methodology for rigorous

development of generic requirements Accepted for Workshop on Rigorous Engineering of Fault Tolerant Systems,

REFT, Newcastle, 2005 [3.4] C. Snook, I. Oliver, and M. Butler.The UML-B profile for formal systems

modelling in UML. In J. Mermet, editor, UML-B Specification for Proven

27

Embedded Systems, chapter 5. Springer, 2004. [3.5] C. Snook and M. Butler. U2B - A tool for translating UML-B models into B. In

J. Mermet, editor, UML-B Specification for Proven Embedded Systems Design, chapter 5. Springer, 2004.

[3.6] RODIN deliverable D2 : Definitions of Case Studies and Evaluation Criteria

Project IST-5111599, November 2004 [3.7] RODIN deliverable D4 : Traceable Requirements Document for Case Studies

Project IST-5111599, February 2005 [3.8] RODIN deliverable D9 : Preliminary Report on Methodology IST-5111599,

Sept 2005 [3.9] RODIN deliverable D14 : Assessment report 1 IST-5111599, Sept 2005 [3.10] Rigourous Open Development Environment for Complex Systems -RODIN

:Description of Work IST-5111599, April 2004 [3.11] C. Snook and M. Butler, “UML-B: Formal modelling and design aided by UML”, Technical Report, Electronics and Computer Science, University of

Southampton. [3.12] J-R Abrial Mechanical Press: Requirement Document Nov 2004

28

SECTION 4. REPORT ON THE CASE STUDY: FORMAL TECHNIQUES IN

MDA CONTEXT

4.1 Case Study Description

This case study is primarily aimed at constructing and verifying platforms rather than aim-ing at the applications themselves. We take the view that with the increased use of technolo-gies such as MDA - which emphasise the role of domain models of applications which areindependent of many implementation technologies - the inclusion of properties such as faulttolerance can be decided and architected upon at a later stage of development in much thesame way as a choice of implementation platform or language can be made [4.18].

It is also commonly true that platforms are being constructed in parallel with the applica-tions that will run upon those architectures; whether this is a good situation or not dependsupon the processes and management involved. Most MDA literature suggests that there is asingle platform and that a PIM is mapped (architected) onto this platform to produced thePSM. We take a more liberal view which states that platforms themselves are collections ofproperties [2] - the theory of this is still under construction in this particular context and willbe expanded upon during this course of this case study.

To fulfil this we aim in this case study to take a more aspect oriented approach to the notionof a platform by weaving together a successive series of platforms each introducing an addi-tion level of detail. Each level of detail (again, the theory about what a level of detail or“abstraction level” is depends upon the defition of what a platform is and how this is phrasedin MDA terminology - we make an attempt in this case study to answer this question). Atleast within the context of RODIN we shall consider fault tolerance to be a platform in its

own right; given our specification of the Nokia NOTA1 platform we will utilise existingtransformations to generate implementation of this, e.g.: C++ (Symbian), Java, SystemC andso on. In addition we shall also produce versions of fault-tolerant version of both the NOTAplatform and NOTA services/applications by mapping the specifications onto the “fault-tol-erant” platform and then to our existing transformations.

A number of particular questions need to be answered:

• How much information about fault tolerance can be axiomsed in this way? A discussionabout the possibilities and limitations is given in [1].

• Does the ordering of transformations make any difference to the overall properties of thesystem; on particular concern here is that transformations may either over-constrain amodel or not be applicable due to variations in the abstraction level of the domain modelfor transformation?

• Given this platform and aspect based approach, how does this affect the placement of fea-tures such as fault-tolerance into the various models being created and how does thisaffect the transformation or weaving process to compose two or more models?

1. Network-on-Terminal Architecture. This is described later in more detail.

29

• How does the effect of using an aspect oriented design flow and composition of modelaffect refinement?

4.1.1 MITA and NOTA

This case study was originally described as MITA (Mobile Internet Technical Architecture).MITA is a large, “grand plan” for the overall structure of the mobile internet. NOTA on theother-hand is one particular implementation of a part of MITA [4.13][4.14][4.15].

NOTA provides us with a more concrete set of requirements but still conforms to the plat-form based, distributed, service oriented nature that was put forward in the original casestudy. As far as the RODIN work is concerned NOTA can be considered a refinement or sub-set of MITA. No changes to the goals of this work have been made.

Additionally we must also consider situations where the services do not follow the rule ofbeing stateless. Combinations of services and applications may themselves deadlock and fail,but the platform must never.

Many defintions of the term service have been proposed. We follow the defintion that a serv-ice is a group of publicly available, common functionalities [4.2].

4.1.2 Network-On-Terminal Architecture

NOTA (Network-On-Terminal Architecture) is a platform for mobile devices for service ori-

ented systems [4.2]1. The platform itself consists of a number of interconnect nodes whichprovide access points for services and applications to communicate. Via these interconnectnodes, a service can register itself so that its features and functionality are globally (we shallreturn to clarify this point) available to other services and applications in the system.

NOTA is envisaged as a platform onto which services and applications can be implemented(it provides services registration, discovery and connection facilities). Services and applica-tions therefore must contain (when made NOTA specific) a certain set of functionalities toremain well-behaved within a NOTA system. Ideally services and applications would be for-mally specified and their compliance formally proven; this might not always be the case[4.24] and the system should be able to recover from mis-behaving services and applications.

4.2 Major Directions in Case Study Development

This first year has seen a change in the application of the RODIN ideas and technologies to amore concrete implementation. However this has given us time to concentrate more onmethodological and theoretical aspects of the ideas being investigated in this case study. Themajor point here is that technologies such as the OMG’s MDA [4.16] are loosely defined andthe ideas being suggested lack a rigorous theoretical basis.

Regarding the actual practical part of the case study we have

1. Also compare NOTA with WSML (Web Services Management Layer) which provides a similar kind of func-

tionality but not in the embedded scales of terminals we are considering here. http://ssel.vub.ac.be/wsml/

30

• Investigated the use of B in distributed systems (via MITA ideas)

• Constructed specifications of the NOTA Platform

• Constructed specifications of potential applications and services that might be based onthe NOTA platform

• Taken initial steps towards understanding how OO/AOP/MDA can be utilised in the con-text of RODIN.

• Taken initial steps towards understanding the role of MDA and formal methods in theconstruction of Service Oriented systems.

• Started investigation of refinement and retrenchment properties between models.

4.3 Achieved Results

4.3.1 Platform Development

Development of platforms is conceptually no different from developing applications them-selves; there are of course differences in practise such that platforms are not normally con-cerned with execution and concentrate more on structure and non-functional properties. Inthis case study we are more focused on the specification of the structure of the platform, itsinternal consistency and how non-function aspects can be specified and validated/verifiedinside the Rodin framework [4.6][4.7]. There exists a large amount of material related to thedevelopment of distributed system in a formal manner, e.g.:[4.9][4.12][4.22][4.27][4.25][4.27]. We are therefore particularly interested in the combina-tion of these formal techniques with MDA and its ideas of model composition throughtransformations.

We consider two aspects of platform development here, the first is related to the MDA devel-opment flow and the role of verification/validation within that flow and the second is relatedto development methods used within Nokia.

The case study is being designed to evaluate the following scenario:

• The platform contains information about where fault tolerance lies and how this is to beachieved.

• Applications are developed independently of this platform. These applications may how-ever contain information about fault tolerance as well as other desired properties.

• These applications may be mapped to many platforms (each having their own structureand properties). In this example we map the application onto NOTA.

The result of this is that we obtain a model of the application now in the context of that plat-form, i.e.: in MDA terms it is a platform specific model of that application.

The results should then show the following

“The (platform independent) application should pass all the required tests, i.e.: it verifiesand is validated according to whatever criteria have been specified at this level.”

31

and similarly for the platform:

“The platform specific model created by the composition or mapping of the applicationonto the platform should satisfy all the relevant criteria respectively.”

We do know from experience that the following scenarios do exist:

• The properties specified on the platform independent application can not always beimplemented by the chosen platforms.

• The composition of properties results in an overly constrained system which then can notperform the tasks or behave in the way initially envisaged.

The former case is often seen when there exists pollution of properties from other levels ofabstraction and platforms into the platform independent model of the application. Thissometimes can not be avoided.

In the second case it is necessary to weaken the specification in such a way that the desiredbehaviour of the application and platform are preserved [4.1]. Weakening specificationsmeans that the refinement relationship breaks and various properties of the system arepotentially compromised [4.5]. Techniques such as retrenchment [4.23] however make thisprocess very explicit and thus safer in the sense that the breaking of the refinement relation-ship is made explicit and can be verified.

4.3.2 NOTA Platform Specification

The interconnect is the platform that is being designed for a new series of mobile devices.This platform is designed to consist of a number of nodes (called interconnects) that arecapable of running applications and services. The actual implementation of these is leftundefined as potentially an interconnect node might be a hardware, software or mixed com-ponent. All interconnect nodes however are capable of communicating by some standardmeans. A model of the interconnect node and related elements is shown in figure 4.1.

The specification here exists at a different “abstraction” level than the service/applicationspecifications. The models here describe the interconnect platform onto which services andapplications are implemented. For example this can be visualised using the Y-model or“standard” MDA approach. Compare this with, for example, the SPARC processor/architec-ture definition from Sun.

Regarding the sockets, an interconnect node keeps track of the sockets that have been cre-ated:

Local Socket

This is a socket between services on the same interconnect node

Remote Socket

This is a socket between a service on the current interconnect node and some otherinterconnect node.

Target Sockets

32

These are sockets which have been requested by other interconnect nodes.

The typical boot sequence is described in the sequence diagram in figure 4.2 on page 6. Notethe artistic license in this sequence diagram, this is due to so vagaries of a so called “UMLcompliant” tool. This diagram shows two cases, namely the boot sequence which creates theinterconnect, its connections and a resource manager; of which there is one in any system.We also describe the starting of a service which registers itself with one of the nodes. Forsimplicity the creation of the sockets to be used during registration is not shown on this dia-gram for brevity.

Before describing the sequence of events for registration it is important to describe infor-mally the workings of each of the operations described in the interconnect node class dia-gram.

InterconnectNode::register

When a service registers, it supplies its service name and properties. These propertiesinclude information about what API the service provides and other information, for exam-ple, security keys etc. This information is forwarded to the resource manager for processing;it is the resource manager that has the responsibility for deciding whether a service is allowedto register and issuing service IDs.

As a return either a service ID and acknowledge is returned or a null value and an error mes-sage (i.e.: RMERROR).

During this process the local Services table must be updated to contain this new service ID.

InterconnectNode::deregister

FIGURE 4.1. Class Diagram of the Interconnect Platform

33

A service announces that it is no longer functioning (termination, fault or any other rea-son for suspension of services) and that it is to be removed from the global pool of ser-vices. This information is forwarded to the resource manager that decides upon thecourse of action. Only services themselves may deregister, a service can not be deregis-tered by another service.

If the resource manager allows deregistration then an acknowledgement is sent back and theservice is also removed from the locals services IDs for that interconnect node. It is also pos-sible that a refusal is made an no changes may be made to the local services. It is possible inthis situation that the service may still be available but refuse all attempts to access it after-wards.

InterconnectNode::connect

A service will connect to another service by its service ID. The sid if local will result inthe creation of a socket to the given service and INSUCCESS is returned along with theid of the socket.

If the sid is not in the local Service table then a connection is made to the resource managerwhich supplies information about the location of the service and whether that service idexists. The resource manager will either respond with RMSUCCESS denoting that the serv-

FIGURE 4.2. Example Interconnect Boot Sequence

34

ices does exist; then a remote socket will be created and INSUCCESS returned along with thesocket id to the service.

If the resource manager refused and returns RMERROR then no socket is created andINERROR is returned.

InterconnectNode::disconnect

The id of a socket is given. This socket must be owned by the requesting sid in whichcase the socket obviously must exist; in all this cases the socket is removed and INSUC-CESS is returned, else INERROR.

InterconnectNode::send

Given a socket id which is owned by the calling service, some data is sent via this con-nection. At this point in time we assume that this is always successful returned INSUC-CESS.

InterconnectNode::getSID

Given a service name string then this initiates a connection to the resource managerwhich returns the SID of the requested service. If this service exists then INSUCCESSand the SID are returned, else INERROR.

InterconnectNode::newTargetSocketRequest

When a connection is made between interconnect nodes by a call to the connect opera-tion, the underlying (or whatever) subsystem makes the “physical” connection. The tar-get interconnect receives a call to make a new socket for the “physical” connection. Ifthis is possible then a new target socket is created, else an error is returned (INERROR).After creation it is necessary to inform the service that this socket is aimed at that asocket is available. If this succeeds then INSUCCESS is returned via this new socket, elseINERROR.

Service IDs uniquely identify a service within the local system (i.e.: current device and asso-ciated peripherals). Service IDs are defined to be an integer value in the range 0..infinity.However a service ID of 0 is always an error. All operations that accept service ID, if theyaccept a service ID of 0 then an error signal is returned, e.g.: RMERROR, INERROR.

4.3.2.1. B Translations

Currently the main focus of development is by constructing the structural models andassigning responsibilities in UML and then writing the invariants and operations in B. Thesetogether are then translated into a pure B representation and then presented to AtelierB fortheorem proving and then additional validation through animation and model checking byProB.

The primary difficulties are at this time:

35

• keeping the B and UML models in sync. Tool support is lacking although work in ongoingwith U2B.

• maintaining consistency across the various projected specifications; B is not object ori-ented.

The specifications currently (at least at this abstraction level) are relatively simple and thenature of B keeps us focused on the visible interfaces and the more declarative aspects of themodelling process. We have a direct comparison here with ongoing (and now in the light ofthe results and techniques here highly modified) work in SDL for constructing specificationsof the interconnect node. The primary result is that the current SDL work has been aban-doned and that any new work is directly based by hand translation from the UML/B to SDL;we are investigating automating this using augmented XML representations of B.

An extract of the specification can be seen below1 - we focus here mainly on the invariantand a number of the operations:

MACHINE notaic...INVARIANT sids <: SID & externalSids <: sids & sockets <: SOCKET & localServices <: sids & address : ADDRESS & resourceManager_interconnectNodeAddress <: ADDRESS & resourceManager_sid <: sids & interconnect_resourceManagerAddress <: ADDRESS & interconnect_resourceManager_sid <: sids & ( not( resourceManager_sid = {} ) => card(resourceManager_sid) = 1 ) & localServices ⁄ externalSids ⁄ resourceManager_sid = sids & localServices / externalSids / resourceManager_sid = {} & localSocketsTo : sockets <-> sids & remoteSocketsTo : sockets <-> sids & localSocketsFrom : sockets <-> sids & remoteSocketsFrom : sockets <-> sids & targetSocketsTo : sockets <-> sids & targetSocketsFrom : sockets <-> sids & dom(localSocketsTo) / dom(remoteSocketsTo) = {}...OPERATIONS

/* OO KLUDGE! */ resourceManagerExternalRegistation = PRE not( resourceManager_sid = {} & resourceManager_interconnectNodeAddress = {} ) THEN ANY newEsid WHERE newEsid : SID - sids & not(newEsid : localServices) & not(newEsid : resource WHEREManager_sid ) THEN externalSids := externalSids ⁄ { newEsid } || sids := sids ⁄ { newEsid } END END ;...rr,ss<--interconnectNode_register(nn) = /* nn is the name of the service, rr is the return code ss is the sid */ PRE nn : NAME & not( interconnect_resourceManager_sid = {} & interconnect_resourceManagerAddress = {} ) THEN CHOICE ANY newsid WHERE newsid : SID - sids & not( newsid : externalSids ) & not( newsid : resourceManager_sid ) THEN sids := sids ⁄ { newsid } || ss := newsid || rr := INSUCCESS || localServices := localServices ⁄ { newsid } END OR ss :: SID || rr := INERROR

1. “...” denote where the specification has been cut

36

END END ;...rr,so<--interconnectNode_connect(cc,ss) = /* cc is the calling service, ss is the sid that it wishes to call to, so is the socket created, rr is the return code */ PRE cc : sids & cc : localServices & ss : sids & not(cc = ss) & not( ss : resourceManager_sid ) THEN CHOICE rr := INERROR || so :: SOCKET OR ANY newso WHERE newso : SOCKET - sockets THEN sockets := sockets ⁄ { newso } || so := newso || rr := INSUCCESS || IF ss : localServices THEN localSocketsTo := localSocketsTo ⁄ { newso |-> ss } || localSocketsFrom := localSocketsFrom ⁄ { newso |-> cc } ELSE remoteSocketsTo := remoteSocketsTo ⁄ { newso |-> ss } || remoteSocketsFrom := remoteSocketsFrom ⁄ { newso |-> cc } || externalSids := externalSids ⁄ { ss } END END END END ;...END

Note the inclusion of (horrors!) such as the first (suitably marked) operation to allow us tosimulate activities external to the interconnect node. In this case to generate a number ofexternal services which may be running on other interconnect nodes other than the current.This is one of the problems when trying to project single classes out of a UML model.

However, the results from theorem proving have shown that the internal structures andbehaviour of the node remain consistent across the operations - this has greatly simplifiedand improved the reliability of the SDL implementation.

Results from this specification’s processing by AtelierB can be seen belowPrinting the status of notaic notaic AutoProved /home/ioliver/BProjects/NOTAIC/notaic.mch+--------------------------------------+-------+------+-------+-------+------+-----+| | NbObv | NbPO | NbPRi | NbPRa | NbUn | %Pr |+--------------------------------------+-------+------+-------+-------+------+-----+| Initialisation | 3 | 7 | 0 | 7 | 0 | 100 || resourceManagerExternalRegistation | 9 | 13 | 1 | 12 | 0 | 100 || createResourceManager | 10 | 14 | 0 | 14 | 0 | 100 || announceResourceManagerLocation | 18 | 0 | 0 | 0 | 0 | 100 || interconnectNode_register | 28 | 13 | 1 | 12 | 0 | 100 || interconnectNode_deregister | 20 | 13 | 1 | 12 | 0 | 100 || interconnectNode_connect | 45 | 16 | 0 | 16 | 0 | 100 || interconnectNode_disconnect | 33 | 6 | 2 | 4 | 0 | 100 || getSID | 39 | 0 | 0 | 0 | 0 | 100 || newTargetSocketRequest | 34 | 6 | 0 | 6 | 0 | 100 |+--------------------------------------+-------+------+-------+-------+------+-----+| notaic | 239 | 88 | 5 | 83 | 0 | 100 |+-------------------------------------

All proof obligations have been discharged - the specification here is relatively simple - in thecases where the interactive theorem prover has been needed the proofs have been dischargedby the predicate prover without difficulty.

Proofs that have not been amenienable this way have invariable lead to discoveries of errorsin the specification itself (misspecification) or misunderstandings in the requirements.

37

It must be stressed that on many occasions we have had a theorem proved specification butresults from the model checking and animation in ProB have shown that the specification iswrong and that the specification is behaving not according to our wishes.

The specification of the sockets is performed similarly:MACHINE socket

SEES notaGenerics

CONSTANTS capacityI, capacityO

PROPERTIES capacityI : NAT & capacityI > 0 & capacityO : NAT & capacityO > 0

VARIABLES incommingBuffer, outgoingBuffer

INVARIANT incommingBuffer : seq(DATA) & outgoingBuffer : seq(DATA) & card(incommingBuffer) <= capacityI & card(outgoingBuffer) <= capacityO

INITIALISATION incommingBuffer := [] || outgoingBuffer := []

OPERATIONS /* API calls to a NOTA Process */ send(dd) = PRE dd : DATA & card(outgoingBuffer) < capacityO THEN outgoingBuffer := outgoingBuffer <- dd END;

dd<--getData = PRE not(incommingBuffer = []) THEN dd := first(incommingBuffer) || incommingBuffer := tail(incommingBuffer) END ;

flushIncommingBuffer = BEGIN incommingBuffer := [] END ;

flushOutgoingBuffer = BEGIN outgoingBuffer := [] END ;

rr <-- isDataAvailable = BEGIN IF incommingBuffer = [] THEN rr := FALSE ELSE rr := TRUE END END ;

/* Calls to the transport layer .. here for convenience to allow simulation of sending the data through a pipe */ pipeSend = PRE not(outgoingBuffer = []) THEN outgoingBuffer := tail(outgoingBuffer) END ;

pipeReceive = PRE not(card(incommingBuffer)=capacityI) THEN ANY dd WHERE dd : DATA THEN incommingBuffer := incommingBuffer <- dd END ENDEND

and similar problems as described earlier have been found here.

Matching the results from the sockets with the results from the interconnect node are prob-lematic. We assume that if it were possible to work in a truly object oriented way then a sys-tem with many concurrent sockets managed by many concurrent interconnect nodes (asaccording to the class diagram in figure 4.1) would be correct. We are currently investigatingways this can be achieved in B without resorting to U2B to generate the specifications.

38

One interesting facet here has been the modelchecking of the behaviour of the sockets. ProBis capable of generating graphs of the state spaceof a machine. We have tools available internallywhich can also explore these graphs and com-pare these with logging information returnedby implementations. An example of the statespace for sockets (with limited SET sizes) canbe seen in figure 4.3.

Despite the apparent incomprehensibility ofthis graph, it is however generated from a repre-sentation in the dot language - part of the

GraphViz graph visualisation package1. Tworesults come from this:

• The textual format is processable asdescribed earlier and can be comparedagainst log files generated from implementa-tions.

• The visual appearance of the graph givesclues to major branching or other problemssuch as deadlocks.

Of course the latter case is purely subjective but generally the “cleaner” the graph looks thebetter.

4.3.3 Example Service Specifications

We present here two potential services that could be implemented upon NOTA. As we havedescribed earlier, the specification of these services is independent of NOTA and could beimplemented on any given platform.

4.3.3.1. Still Camera Service

The basic functionality of a camera service is to make available the API functions for takingpictures (obvious). In this case there are five pieces of functionality that we consider:

• taking a single picture

• taking multiple pictures (aka multishot mode)

• changing the number of pictures to be take in multishot mode

• changing between multishot and single shot modes

• changing between camera states (i.e.: on, standby etc)

1. http://www.graphviz.org/

FIGURE 4.3. State Space Graph forSocket.mch

39

The UML description for a camera is fairlysimple as can be seen in the figure 4.4 whichshows the simple class diagram and figure4.5 which describes the behaviour in termsof an orthoginal state machine.

The attributes and operations have the fol-lowing natural language specifications:

multipleShots: this is a value between 2and 10 which states how many shotsshould be taken sequentially in multi-ple shot mode

takeSinglePicture: the camera must be in the on state and multiple shot mode must beoff. The result is a single picture returned.

takeMultiplePicture: the camera must be in the on state and multiple shot ode must beon. The result is a set of pictures - the number of which is given by the number of multi-ple shots to be taken.

changeMultipleShots: this accepts an integer which is used stored in the multiple shotsattribute

startCamera: switch the camera to on mode - this can occur at any time

stopCamera: switch the camera off - this can occur at any time

gotoStanby: this places the camera is stand by (aka power save) mode. This mode canonly be activated from the on mode. This operation would not normally available to theuser.

The camera can be considered at any point in time to be in certain discrete states which canbe represented by an orthogonal state machine shown in figure.

FIGURE 4.4. Class Diagram of Still Camera

FIGURE 4.5. Still Camera State Machine

40

What is not shown in this example is the specification of the specifics of the behaviour. Thisis embedded inside the elements diagram as allowed by the various tools in use.

4.3.3.2. Storage Service

The storage service provides a common API to all storage devices. The basic functionalityprovided is:

• storing of items (files)

• retrieving of items (files)

• overwriting of items (files)

• deletion of items (files)

• renaming of items (files)

The UML class diagram of the storage is shown in figure 4.6 and as before the natural lan-guage specifications of the attributes and operations are given as below.

items: the set of items that the storage contains - basically an index or directory. Eachitem has a unique name

store: takes an item and name and stores it. An item with the given name must notalready exist in the storage

retrieve: given an name that exists in the storage, returns the associated item

rename: given a name of an item that exists in the storage, changes its name to the newgiven name. The new name must not previously exist in the storage

overwriteItem: given a name and item where the name already exists in the storage,overwrite the currently stored item with that name with the given item.

FIGURE 4.6. Class Diagram of Storage

41

deleteItem: given the name of an item that already exists in the storage, remove that itemand the corresponding name.

Similarly the storage specification in B is very simple and is concerned with maintaining theset of items:

MACHINE storage

SEES generics

VARIABLES items

INVARIANT items : NAME <-> ITEM

INITIALISATION items := {}

OPERATIONS storeItem(ii,nn) = PRE nn : NAME & ii : ITEM & nn /: dom(items) THEN items := items ⁄ { nn |-> ii } END;

overwriteItem(ii,nn) = PRE nn : NAME & ii : ITEM & nn : dom(items) THEN items := items <+ { nn |-> ii } END;

ii <-- retreiveItem(nn) = PRE nn : dom(items) THEN ii := items(nn) END;

deleteItem(nn) = PRE nn : dom(items) THEN items := { nn } <<| items END;

renameItem(oo,nn) = PRE oo : dom(items) & nn : NAME & oo : NAME & nn /: dom(items) THEN items := items - { oo|->items(oo) } ⁄ { nn|->items(oo) } ENDEND

Again all proof obligations were discharged without problem.

4.3.3.3. Example Camera Application Specification

We now describe an simple application that utilises the services described above. This appli-cation manages the available cameras and storage devices and simple allows the user tochoose between these and take photographs. The photograph is then stored by the selectedstorage service.

There application also keeps track of the last picture taken. This application at this timeinsists that the camera only takes single shots (i.e.: multishot mode is always off).

42

The model describing the structure of this application can be seen in figure 4.7 and similarlythe natural languages descriptions of its functionality below:

The following are natural language specifications of the attributes and operations of the cam-era application:

localPicture: contains a picture which is the last picture taken by the camera

availableCameras: lists all the available camera (services). Some mobile devices havemore than one camera device.

availableStorage: lists all the available storage (services). Some mobile devices have morethan one storage device.

selectedCamera: points to the currently selected camera, which must be available to thecamera application.

selectedStorage: points to the currently selected storage which must be available to thecamera application.

selectCamera: chooses one of the available cameras

selectStorage: chooses one of the available storage services

photograph: take a photograph. The photograph will be stored as the localPicture and beautomatically stored by the selected storage service. An example of this in use can beseen below.

FIGURE 4.7. Class Diagram of Simple Camera Application

43

The workings of the photograph() operation is described using the interaction diagram infigure 4.8.

To construct the application we must compose the specifications for storage, camera and theapplication itself. The first major problem here is that we need individual objects to representvarious instances of cameras (e.g.: the Nokia 6680 has two individual cameras), similarlystorage, most mobile devices have memory cards, SIM cards and even hard disks; off-devicestorage is also possible.

4.3.3.4. Commonalities

When working at this “domain” modelling level with the services and applications we havefound it necessary to augment the basic UML with a number of stereotypes and also we haveidentified a number of common generic artifacts.

The stereotypes are simply <<service>> and <<application>>. These are applied to the classwhich takes the role or responsibility of managing the collaborations in that service or appli-cation.

The <<service>> stereotype states that this particular structure will be thought of as a service- that is in the future it may become (platform permitting) some kind of service component.It is envisaged that services in the future will be placed in some kind of respository to form alibrary of standard services; cf. standard libraries in some programming languages/environ-ments.

Similarly the <<application>> stereotype states that this particular structure will be thoughtof as an application.

FIGURE 4.8. Interaction Diagram for photograph() Operation

44

The primary difference here being is that services can be used by anything, while applica-tions only call services. Applications can not be called or used as services.

The common or generic artifacts relate tomore the standardisation of a set of datatypes or classes found at this level. The classdiagram in figure shows these currently.

An item is any piece of data (or in object ori-ented terms, an object of some kind), a pic-ture is a special kind of object and a name issome way of naming something. Items mayor may not have names. Within a givennamespace, two items with the same nameare necessarily identical. The definition ofnamespace however is lacking at this point intime other than some informal, “common sense” meaning.

4.3.4 Object Orientation in B

One of the major issues to be tackled in this work is how to combine object orientation witha formal specification language such as B which does not directly support object orientedconcepts such as inheritance, polymorphism or the class-object dichotomy.

One issue is the tools that are available [4.4], in previous projects (PUSSEE [4.12]) we haveutilised the U2B tool [4.26] to automate the translation from UML to B. Currently in theRodin project the tools are unavailable; usage of U2B at the moment is difficult due to thedifferences in tool chain and that most projects now rely upon the UML 2.0 XMI representa-tion which can not be read by U2B at present. While useful, U2B still has limitations such asit does not handle inheritance and that the UML models have their attributes, invariants andoperation pre/post conditions written in B - one might argue that B as a constraint languageto UML is not a bad thing, but unlike OCL, B is not integrated with the UML meta-modeland lacks certain constructs for navigation expressions, typing etc.

The specifications so far discussed in this document have been hand translated either in thestyle of a U2B translation which embeds the object oriented management constructs into theB in much the same way as early C++ compilers produced convoluted C code to emulatethese features directly. The second option has been to individually translate each class as asingle B machine construct and attempt to “hide” other classes by presenting these as simpleset structures (using B’s SETS construct). This latter method is a kind of projection of variousstructures in the model and while simplifying the specification in B does not allow the wholemodel to be checked at once.

Neither method is wholly satisfactory at this time but the B produced is amenable to sensibleverification and validation, although we do have a number of difficulties proving certainconstructs due to the added complexity of the OO management constructs. Particular suc-cess has been had using the ProB animation/model checking environment to assist in under-standing the relationships (maintenance of relationships between elements of setsrepresenting objects).

FIGURE 4.9. Domain Level Generic

45

We are also currently investigating projecting the inheritance (specialisation/generalisation)structures out of the UML model so that classes can be represented as B machines and theinheritance relationship as refinement relationships between machines. This gives a verystrict interpretation of inheritance but allows an alternative way of asserting the Liskov Sub-stitution Principle [4.8]. This method however would not admit multiple inheritance [4.3];one hypothesises here that the machine inclusion mechanisms might be more appropriate inthese situations but one loses the refinement proof obligations.

4.3.5 Theoretical Basis of MDA

We have an outline of a categorical semantics for MDA. This theory provides semantics tothe notions of model, platform, language, development flow and the relationships betweenmodels: refinement, transformation and translation.

It is hoped that this work will be finalised before the end of this year. The development andapplication of this theory in being made within the context of this case study and variousprojects outside of Rodin, e.g.: Åbo Akademi’s Coral tool.

4.4 Demonstrators and Evaluation

The evaluation plan described in Rodin Deliverable D1.1 identifies the following criteria forthis casestudy; we provide some evaluations from the work performed so far:

• How well does this formal approach fit with existing processes?

Any formality or rigor in any engineering exercise improves some aspects of the qualityof the finalised product. At least the experiences within MITA and NOTA on construct-ing a specification with the required platform abstraction and formality has lead toresults showing potentially gross errors in the existing (non-formal) specification.

• How well do these techniques integrate with an object-oriented approach?

This still needs more analysis but current results point to (once again) the semantic gapbetween object-oriented and structured decompositions.

• In what form are these technologies transferred to the Nokia Business Units?

The ideas and concepts have and are being successfully transferred to various commer-cial products. This has been primary in the way of thinking that is being employed andthe emphasis on clear and precise requirements/specification and platform independentdesigns. The transfer of verification techniques however is still a problem.

• Can this approach check components against a (very loose) specification?

Yes, but this still needs more analysis before a clear conclusion can be made on this.

• What is required to understand over constraint models, their causes and effects?

This has so far only manifested itself either as coding errors in the specification or as apointer to mixing abstraction levels (i.e.: platform or architectural pollution of a model).

46

Investigations of this phenomenal during MDA style transformations will be investi-gated during the next steps of this case study.

• Can this approach deal with requirements volatility?

Techniques such as retrenchment are known to handle this, though there are method-ological and theoretical issues here. The existing specification has been reworked anumber of times with respect to addition feature requirements but more substantialchanges need to be investigated in more detail.

4.5 Summary

Work on this casestudy is progressing well now that steps have been taken to more concretisethe application from a very generic distributed framework such as MITA into NOTA

The results of this work with an existing project within Nokia Research has been extremelybeneficial but of course has lead to a number of other issues such as how to capitalise on thisearly specification and verification/validation work later in the development process.

Preliminary results in terms of time spent working with requirements is showing a 60-70%decrease in time spent developing the system from specification to prototype. However someof this can be explained by the personnel involved at this time, e.g.: experts in SDL/C++ cod-ing, B, verification etc. We would expect to see a 30% increase in productivity (equatablewith 30% decrease in development time with a more correct product at delivery) once thesetechniques are more established.

The work will continue in the following fashion; firstly the various specifications will becomposed, i.e.: stillCamera, store and the simple camera application will be made NOTAspecific using a transformation (MDA mapping/transformation). Via this we will investigatewhether or not the transformations are simply superpositions or whether additional effectsare introduced.

Secondly the set of fault tolerant properties will be decided upon and these will be integratedagain using transformations, i.e.: fault tolerance being considered a platform. We will investi-gate fault tolerance as a platform with respect both to services/applications and the NOTAplatform itself. Various combinations of fault tolerant services/applications and the NOTAplatform will be tried and analysed for their respective properties.

4.6 References

4.1 Thomas Bolusset, Flavio Oquendo (2002). Formal Refinement of Software Architec-tures Based on Rewriting Logic. RCS’02 International Workshop on Refinement of CriticalSystems: Methods, Tools and Experience, January 22, 2002 - Grenoble - IMAG

4.2 Manfred Broy (2004). From Objects to Components to Services - A formal frameworkfor service-oriented architectures. WICSA, 4th Working IEEE/IFIP Conference on SoftwareArchitecture. June 2004. Oslo, Norway.

4.3 Luca Cardelli. A Semantics of Multiple Inheritance (1988). Information and Computa-tion 76:2-3, Feb/March 1988, pp 138-164.

47

4.4 Bernhard Steffen (2004). Major Threat: From Formal Methods without Tools to Toolswithout Formal Methods. ICECCS 2004:

4.5 Andrea Kerschbaumer (2002). Non-refinement Transformations of Software Architec-tures.Formal Refinement of Software Architectures Based on Rewriting Logic. RCS’02 Inter-national Workshop on Refinement of Critical Systems: Methods, Tools and Experience,January 22, 2002 - Grenoble - IMAG

4.6 #I. H. Krüger, R. Mathew: Systematic Development and Exploration of Service-OrientedSoftware Architectures. Proceedings of the 4th Working IEEE/IFIP Conference on SoftwareArchitecture (WICSA 2004), 2004.

4.7 #I. H. Krüger, D. Gupta, R. Mathew, P. Moorthy, W. Phillips, S. Rittmann, J. Ahluwalia:Towards a Process and Tool-Chain for Service-Oriented Automotive Software Engineering.Proceedings of the ICSE 2004 Workshop on Software Engineering for Automotive Systems(SEAS), 2004

4.8 Barbar Liskov, Jeannette Wing (1993). Family Values: A Behavioral Notion of Subtyping.Technical Report MIT/LCS/TR-562b.

4.9 Shaoying Liu (2004). Formal Engineering for Industrial Software Development.Springer. 3-540-20602-7

4.10 Tiziana Margaria (2004) Modelling Dependable Systems: What can Model DrivenDevelopment Contribute and What Likely Not? ISORC 2004, 7th IEEE Intern. Symposiumon Object-oriented Realtime distributed Computing. May 12-14, 2004, Vienna (A), IEEE CSPress, pp. 113-120.

4.11 Tiziana Margaria, Bernhard Steffen (2003). Aggressive Model-Driven Development:Synthesising Systems from Models viewed as Constraints. The Monterey Workshop Series2003 Theme: Workshop on Software Engineering for Embedded Systems: From Require-ments to Implementation, Chicago, Illinois, September 24-26, 2003.

4.12 J Mermet (editor) (2004). UML-B Specification for Proven Embedded Systems Design.The ChDL Series. Kluwer Acadmic Publishers. 1-4020-2866-0.

4.13 Nokia (2002). Mobile Internet Technical Architecture. Technologies and Standardiza-tion. ITPress. 951-826-668-9

4.14 Nokia (2002). Mobile Internet Technical Architecture. Solutions and Tools. 951-826-669-7

4.15 Nokia (2002). Mobile Internet Technical Architecture. Visions and IMplementations.951-826-670-0

4.16 Object Management Group. Model Driven Architecture. http://www.omg.org/mda

4.17 Object Management Group. Unified Modelling Language. http://www.omg.org/uml

4.18 an Oliver (2004). Model Based Development and Embedded Systems Design. FDL04Special Session on MDA in Embedded Systems Development.

4.19 Ian Oliver (2004) Some Issues in Rigorous System Design in a Model Driven Develop-ment Context. ECSI UML-SystemC System Design Flow Workshop. May 4, 2004, Lille,France

4.20 Ian Oliver (2004) Model Based Testing and Refinement in MDA Based Development.In: Proceedings of Forum on Design Languages FDL’04. September 14-17 2004, Lille, France.

48

4.21 Pankaj Palote (1998) Fault Tolerance in Distributed Systems. PTR Prentice Hall. 0-13-301367-7

4.22 J.Plosila, K. Sere and M. Waldén, Design with Asynchronously Communicating Com-ponents. In FMCO 2002: First International Symposium on Formal Methods for Compo-nents and Objects, Leiden, The Netherlands (November 2002), LNCS. Springer-Verlag.

4.23 M. Poppleton, R. Banach (1999) Retrenchment: Extending the Reach of Refinement.IEEE ASE-99, 158-165

4.24 Alastair D Reid (1993). A Precise Semantics for Ultraloose Specifications. MSc Thesis.University of Glasgow

4.25 Bran Selic, Garth Gullekson, Paul T. Ward (1994). Real-Time Object-Oriented Mode-ling. Wiley Professional Computing. 0-471-59917-4

4.26 Snook, C., Butler, M. and Oliver, I. (2003) Towards a UML profile for UML-B. Techni-cal Report DSSE-TR-2003-3, Electronics and Computer Science, University of Southampton.

4.27 C. Snook, L. Tsiopoulos and M. Waldén, A case study in requirement analysis of con-trol systems using UML and B. In Proceedings of RCS’03 - International workshop onRefinement of Critical Systems: Methods, Tools and Experience, Turku, Finland, June 2003.Also as: TUCS Technical Reports, No 533, Turku Centre for Computer Science, Turku, Fin-land, June 2003.

49

SECTION 5. CASE STUDY 4 — CDIS AIR TRAFFIC CONTROLDISPLAY SYSTEM

5.1. Introduction

The CDIS case study is aimed at providing feedback into the methodological and tool platformworkpackages. While much of the initial work on this case study involves reviewing CDIS doc-umentation, this process is extremely productive in providing challenges to the methodologicalresearch.

In early 2005 the first task of generating a subset of the original CDIS specification was com-pleted. The first draft of the subset was discussed in a meeting at Newcastle on December 14th,2005, where the degree to which things like concurrency and fault tolerance would be includedwas considered. The decision to draw the subset from a “vertical” slice of the original CDISspecification was generally agreed to be the best way to get a usable chunk of material.

The next meeting, held on January 20th and 21st, 2005, in Newcastle, was an opportunity todiscuss the penultimate version of the CDIS subset. The entire context of CDIS was discussed,with respect to both the subset and the entire CDIS specification. A large part of the meet-ing was given to discussion of the problems initially faced during CDIS development, howthey manifest in the subset, and the nature of the challenge the problems pose to the RODINmethodology. The January meeting also gave an opportunity to plan the first steps of how thesubset would be redeveloped using the RODIN methodology.

The RODIN Plenary meeting at Nokia Research in Helsinki at the end of March gave a chanceto present the subset and some of the work done on redevelopment to the wider RODIN com-munity, and solicit feedback and view on the case study’s progress.

5.2. Major Directions In Case Study Development

5.2.1. Nature of CDIS

CDIS was a technically successful project with exceptionally low defect rates for its time, andany new method must at least maintain the features that contributed to that success. At the sametime, there were substantial technical difficulties which we would hope could be addressed bya more modern approach to the specification and design.

There are particular characteristics of CDIS that are relevant to the choice of method:

50

• CDIS is a data-intensive system. It contains large collections of disparate data and itsbehaviour is described by changes in that data. This is in contrast to, for example, controlsystems which are typically finite state and have only single instances of each kind ofdata.

• CDIS has a large external interface. Indeed its whole purpose is to display information.The specification is therefore large in terms of the number of operations and the numberof inputs and outputs for each operation.

• CDIS does little processing. There are almost no interesting algorithms in CDIS, and thespecification is shallow: each operation has a simple though voluminous definition.

• CDIS is a highly distributed system. It exhibits a high degree of concurrency, and theidea of an atomic operation is a very loose approximation to its actual behaviour.

There are five major areas that the case study needs to address:

1. ComprehensibilityAny system specification needs to be understood by all the stakeholders. The formalnotations1 in CDIS were a barrier to understanding by many stakeholders.

2. ModularityThe original CDIS specification and design take thousands of pages. A good modularitymechanism is essential.

3. Concurrency

(a) We have no formal ways of reconciling the atomic operation model with the realconcurrent behaviour

(b) We needed different, unrelated notations for sequential and concurrent specifica-tions.

4. RefinementConventional models of refinement are quite inadequate to express the change of struc-ture between the specification model and the design model.

5. ProofIt was completely infeasible to carry out proofs on a specification of this size.

5.2.2. Comprehensibility

The case study needs to ensure that the new specification is comprehensible to stakeholders. Itneeds to be capable of expressing stakeholder concepts in a direct way rather than having totranslate them into some obscure (even if faithful) representation. For example, notions such asaggregation, sequencing and optionality of data must be directly expressible in the specificationlanguage.

1Principally VVSL — VDM augmented with modularization constructs

51

EDD DISPLAY operations

DELETE PAGE deletes a public page and all its versions.

traceunit SPEC.EDD DISPLAY.DELETE PAGE.OP

DELETE PAGE(pageno : Page number)

edd dspl updates : EDD displays

ext wr pages : Pageswr version sets : Version setswr checked out : Checked outwr edd pages : EDD pageswr edd displays : EDD displaysrd page selections : Page selectionsrd preview selections : Preview selectionsrd time now : Date time

pre true

check can delete page(pageno,↼−−−pages ,↼−−−−−−−−version sets)

post page deleted(pageno,↼−−−pages , pages,↼−−−−−−−−version sets, version sets)∧page deleted(pageno,

↼−−−−−−−−−−−−−edd acks required , edd acks required ,

↼−−−−−−−−−−−−−concealed displays , concealed displays,↼−−−−−−−−edd displays , edd displays,

↼−−−−−−edd pages , edd pages,

edd dspl updates, page selections, preview selections,pages, time now)

explanation It is not feasible to check that a page is not being displayed or previewed at a userposition.

106 S.P1286.50.4/Issue 0.2 c©2004,2005 Praxis High Integrity Systems

Figure 5.1: The VVSL specification for Deleting Pages

5.2.3. Modularity and size

VVSL [5.6] has a modularity mechanism similar to VDM-SL [5.2]. It allows types, state andfunctions visible in one module to be used in another. It also contains a good mechanism— perhaps better than any other specification language — for expressing error behaviour. Inspite of this, the CDIS specification is extremely verbose. The main reason is that there is nogood mechanism for modularising the definition of operations. Figure 5.1 is an example ofan operation definition from the subset. This specification is simply importing the three partialdefinitions, but it requires a huge amount of boilerplate to make it a correct VVSL specification.There is currently no completely satisfactory solution to this problem. For example, while

DeletePageDeletePageFromPagesDeletePageFromDisplays

CanDeletePageFromPages

Figure 5.2: Z Schema for Deleting Pages

52

the schema calculus in Z [5.7] has limitations, although the corresponding Z specification inFigure 5.2 would certainly be more palatable.

Any new notation needs to allow specifications that are closer to Figure 5.2 than Figure 5.1.

5.2.4. Concurrency

It is obviously useful to separate concerns about behaviour from concerns about concurrency.However, it is also necessary to bring together the two views of the system, and in CDIS weweren’t able to do that very effectively. There are two issues: the approximate nature of theVVSL specification and the incompatibility of notations.

5.2.4.1. VVSL versus reality

The VVSL specification of the operation to release page states that all workstations that aredisplaying the page simultaneously switch from displaying the old version to displaying thenew one. This is not necessarily what the system actually does: the different workstations maytake varying lengths of time to do the switch. There are many similar examples in CDIS. Themethodological challenge that this poses is whether there is a justifiable retrenchment from thestrict specification to some looser (and presumably more complex) specification that describesthe real behaviour. The reason this is so desirable is that the initial strict specification is rel-atively simple and captures the essence of the operation; the complexity of non-simultaneousupdate is really a separate issue. Furthermore one would like to have a single generic way ofretrenching all the different operation specifications, rather than cluttering each one with thedetails of non-simultaneity.

5.2.4.2. Notations

Although VVSL does have a notation for concurrency, it was not in practice usable. Thereforewe had to use quite separate notations such as CSP or CCS (as well as informal notations likedata flow diagrams) to describe concurrency. There is therefore no formal connection betweenthe sequential and concurrent specifications. The case study needs to demonstrate that Event-Bcan integrate the different aspects while still allowing different concerns to be treated fairlyindependently.

5.2.5. Refinement

VDM [5.5] (on which VVSL is based) and Z have a simple model of refinement in which statecan be made more concrete and operations can have their preconditions weakened and post-conditions strengthened. This notion doesn’t begin to address the complexities of design of a

53

distributed concurrent system like CDIS. Nor does it capture the idea of viewing an operation atdifferent levels of granularity, which is essential if the initial specification is not to be clutteredwith too much detail.

5.2.5.1. Concurrency and distribution

State is split over many machines; operations involve several different processes and messagesbetween processes and machines, so the set of operations in the design is far richer than the setof operations in the specification. A single specification level operation may require multipleinstances of several design level operations and messages, while a single design operation maycontribute to many different specification level operations. We need a calculus of refinementthat allows such structural changes to be expressed.

5.2.5.2. Granularity

At one level, we do not worry about how inputs to operations are provided. The VVSL op-eration to display a page, for example, has an input of type Page Number. At another level,however, we need to specify exactly how this input is derived from user actions. For example,the page number is typed on a special keypad and there is quite a complex protocol to allow theuser to change their mind or do something else in the middle of selecting a page. We did nothave any formal way of relating these two views of the operation. The protocol was describedas a finite state machine but its connection to the VVSL was entirely informal.

5.2.6. Proof

As CDIS is a shallow but large system, there is a huge volume of relatively trivial proof obli-gations. It is important that the tools are capable of carrying out the necessary proofs with aminimum of human intervention, since the sheer volume would make it impractical to do theproofs by hand.

Of course, while the specification level proofs are trivial, proof obligations introduced by themore complex refinement rules mentioned in section 4 may not be. There will also be a verylarge number of such proof obligations.

5.3. Achieved Results

There are two major results to date in this case study. The first is the subsetting of the originalCDIS specification to a usable set of documents for the project. The rationale behind theselection is described in the next section.

54

The second major result is our work on the redevelopment of CDIS in the RODIN notations.This work has been done at Praxis and Southampton, each following a different approach. Bythe plenary meeting at Helsinki we decided that the approach initially taken at Praxis would notbe the best option. The reasons for choosing not to redevelop the subset first in classic B [5.1]notations are given in Section 5.3.2.

5.3.1. Content and rationale for the CDIS subset

CDIS is an operational system supplying flight data, airport data and other support informationto air traffic controllers in the London Terminal Control Centre at West Drayton. It was deliv-ered in 1992 and went operational in 1993. Since then it has been maintained by Praxis andsubsequently by NATS: some parts of the original system have not been used, others have beenchanged and new facilities have been added. The subset used in this case study is based on thesystem that was originally delivered.

There is a brief overview of CDIS and a description of the specification and design approachused in an IEEE Software article [5.3]. The subset is fully described in a project document [5.4].

The RODIN subset includes only airport data. The subset has been chosen to be small enoughto be manageable while retaining some of the main features of the CDIS specification anddesign. In particular it includes enough to illustrate:

• the distributed nature of CDIS

• the necessary size of the specification, which required us to spread the definition of op-erations over several modules;

• the existence of concurrency in the inputs to CDIS, and the extra concurrency introducedby the distributed design; and

• the need for several different aspects (user interface, functional and concurrency) of spec-ification and design.

The subset documents are:

• Requirements

– Semi-formal requirements definition including tracing

– Interface control document

• Specification

– A core specification written in VVSL [5.6], where each operation is modelled as anatomic change of state.

55

– A concurrency specification that describes where the atomicity assumptions of thecore specifcation breaks down.

– A user interface definition that describes the concrete appearance of inputs andoutputs.

• Design

– Application design which defines how the functionality of the core specification isimplemented.

– Process design which describes the behaviour of each concurrent process in theimplementation.

– Specification of low-level services relied on by the implementation.

5.3.2. Redevelopment Work

Southampton has been looking specifically at the requirements document and specificationdocuments of the Praxis case study. Therefore, at this stage, we have ignored all design andinterface documentation. The aims of this case study are somewhat different from the other casestudies because our goal is to use the development of (a subset of) an existing air-traffic controlsystem to assess the performance of the methodologies evolving within the RODIN project.Hence, there is an immediate conflict: in order to assess the new methodologies, we need to beable to compare our models with those of the original development, but the methodologies (inparticular Event-B) do not necessarily facilitate this assessment.

Even though classic B has many similarities with VDM (the underlying specification languagefor CDIS), and there has been work done on converting one notation into the other, Event-B is a fairly radical departure from its ancestor. This is especially true for the structuring oflarge specifications. At Southampton, therefore, we do not consider a ‘translation’ to playa significant part in this case study. Instead, we propose to use the original specification asa guide to refinement from a more abstract viewpoint. This will also allow us to highlightdifferences between Event-B and classic B.

The main features of the CDIS specification is its size and complexity. While it is inevitablethat large real world problems will produce large and complex specifications, facilities shouldbe provided by the specification language for managing such complexity. These structuringmechanisms have a significant influence on the development process. In Event-B, two ap-proaches to the structuring of large specifications have been proposed: generic instantiationand decomposition. In the next two sections, we consider whether these approaches can beapplied to CDIS.

5.3.3. Generic Instantiation

Refinement is the means by which more and more complexity is added to an abstract specifi-cation in order to move formally towards an implementation. Rather than performing a single

56

Development 1 Development 2

Instantiation

M1 C1

Mn Cn

N D

N D

M1’

Mn’

sees

sees

refines

sees

refines

refines

sees

refines

refines

sees

refines

seesrefines

refines

Figure 5.3: An instantiated refinement of development 2

linear refinement, it is possible to perform separate refinements which can be combined at alater stage.

A formal development in Event-B is said to be generic with respect to the sets and constantsaccumulated during the development because these can be viewed as parameters to the de-velopment. By instantiating these sets and constants with the sets and constants of a seconddevelopment, we can get an instantiated refinement of the second development via the refine-ment steps of the first development providing certain proof obligations are fulfilled.

Informally, the proof obligations require:

• the properties of the constants of the second development to imply the (instantiated)properties of the first development,

57

META_DATA

PAGECONTENTS

RECORDS

DISPLAYMODEL

CONTEXT

sees

seessees

sees

Figure 5.4: A model for a generic display

• the most abstract model of the first development to refine the most concrete model of thesecond development.

This is depicted in Figure 5.3 (where the models M′1, . . . , M′

n are the instantiated models M1,. . . , Mn).

By using the core specification of CDIS as a guide, we can start from a more abstract viewpointby constructing a model of a generic display system. The context for this generic model ismade up of a hierarchy of three sub-contexts and one model (see Figure 5.4). The three sub-contexts are generalisations of the modules AIRPORT META DATA, AIRPORT RECORDSand AIRPORT PAGE CONTENTS in the core specification. By abstracting away the airport-specific details, we get a clearer picture of the display functions of the system. At a later stagein the development, we can instantiate this model with the airport-specific details from whichthe Event-B model can be refined.

• META DATA. In the core specification, this module defines types for attribute iden-tifiers and values for the airport and runway data. Here, we declare generic types forattribute identifiers and values in the SETS clause

– Attr id

– Attr value

• RECORDS. By including META DATA via a SEES clause, we define a generic typefor records as a mapping from Attr id to Attr value

– Records ∈ Attr id → Attr value

• PAGE CONTENTS. Here, we define types for the layout of generic pages. We considereach page to be made up of a background and a number of fields corresponding to the

58

position and appearance of values of attributes2

– Page contents :: background : Graphic backgroundfields : ℘(Graphic field)

– Graphic field :: id : Attr idposn : Field positionpresn : Attr value → Fld disp desc

The type Fld disp desc is meant to represent the device-independent ‘appearance’of fields. Hence, the function presn maps values (for a particular attribute) to theirappearance.

– Page disp desc is a type representing the device-independent ’appearance’ of apage. The intention is to combine a background with a set of Fld disp desc (to-gether with their respective positions) to form a value of type Page disp desc thatrepresents the value of a single page.

Given the state that defines actual records, page contents and displays, it is then possible todefine events that compute the appearance of displays. This is depicted as the model DISPLAYin Figure 5.4.

Once this development has been shown to behave as expected, it would be possible to instantiatethis with specific airport attributes and values from which further refinements can be made.

5.3.4. Decomposition

This approach aims to reduce the size of a model by decomposing it into a number of smallersub-models. This involves partitioning the events and variables so that the events of one sub-model do not affect the variables of the other sub-models. Hence, decomposition aims todistribute the model so that certain elements can be seen to be ‘remote’ from other elements.

Communication between distributed elements is achieved through the use of shared (or ex-ternal) variables (i.e. state variables that are common to more than one element). Unfortu-nately, the CDIS core specification does not exhibit this structure. It is more reminiscent ofthe INCLUDES mechanism in classic B, in which an operation of the including machine cancall separate operations of the included machines to update their respective states. However, ifwe are prepared to deviate from the structure of the original specification then it is possible tomake use of Event-B’s decomposition mechanism.

It is possible to decompose the DISPLAY model given in Figure 5.4 into three sub-models: arecords model, a page contents model and a (new) display model (this is shown in Figure 5.5).One can imagine partitioning the events in DISPLAY accordingly: record-updating events be-long to the records model, page-updating events belong to the page contents model, and display

2The record notation used here is part of our proposal to extend B with record types. Details of this can befound in the D9: WP2 Deliverable D2.1 document.

59

NEWDISPLAY

refines refinesrefines

DISPLAY

MODELRECORDMODEL

PAGE

Figure 5.5: A decomposition of DISPLAY

META_DATA

PAGECONTENTS

RECORDS

seessees

NEWDISPLAY

PAGEMODEL

RECORDMODEL

seesseessees sees

Figure 5.6: Putting it together

events belong to the display model. In this decomposition, the shared variable is the state rep-resenting the actual displays because any attribute update will affect the display of its value,and similarly, any update of the page contents will also affect the display. The combination ofthe context of Figure 5.4 and the decomposed model of Figure 5.5 is shown in figure 5.6. Notethat the new models only need to see a subset of the context. That is, RECORD MODEL doesnot need to see the PAGE CONTENTS sub-context, and PAGE MODEL does not need to seethe RECORDS sub-context. NEW DISPLAY requires both sub-contexts.

5.3.5. Other Issues

Another source of complexity within the CDIS core specification is the abundance of uniontypes. Whenever these types are used as parameters of functions, the body of the functioninevitably comprises a complicated case statement which is difficult to understand. During theearly stages of the development it would be beneficial to keep these component types separate,and to define specialised events for each case. Indeed, the bodies of events in Event-B do notallow branching.

60

The VVSL extensions that enable error handling within functions as well as operations arenot present in B. The specialisation of events appears to be one way in which error handlingcan be incorporated into an Event-B specification. One can then, for example, define eventscorresponding to exceptional circumstances in order to meet the robustness requirements of thesystem.

5.4. Demonstrators

The Event-B models and specification document for the CDIS subset form the tangible demon-strator for this particular case study. These models, when used with the RODIN tools, shoulddemonstrate the tools’ applicability and usefulness with respect to industrial-sized projects.

5.5. Future Development

The CDIS case study has already proved to be very beneficial to the project. Although itcontains only a relatively small subset of the original CDIS specification, it is nonethelesslarger than most research case studies and it is rich in “real world” complexities.

Less progress has been made in reworking the CDIS specification and design using the RODIN-nominated notations (Task 1.4.4) than we might have been wished; however, (as in all scientificexperiments) it has been the difficulties and failures that have been the most instructive. Inparticular, it has become clear that any naive attempt at direct translation of the CDIS VVSLspecification into Event-B will simply reproduce the size and complexity deficiencies of theoriginal in a new form.

Future work on Task 1.4.4 will not pursue that approach further but will, instead, focus on fur-ther development of the work started at the University of Southampton as described in section5.3.2. This approach attempts to make use of the possible new strengths of the Event-B nota-tion to create a new specification from the CDIS requirements. The existing CDIS specificationwill serve a guide for the refinements needed rather than as a detailed route map. The strengthof this approach is that it will much better serve to evaluate the benefits of Event-B. A potentialdrawback is that the resulting specification might be quite different in form from the originalVVSL specification, thus making it harder to show that the Event-B version is in some wayequivalent to it. The continuing work in this area will provide inputs to further methodologicalinvestigations (WP2) and the tool development tasks (WP3 and WP4).

5.6. References

[5.1] J.-R. Abrial. The B-book: assigning programs to meanings. Cambridge University Press,New York, NY, USA, 1996.

61

[5.2] J. Dawes. The VDM-SL Reference Guide. Pitman Publishing, 1991.

[5.3] A. Hall. Using formal methods to develop an ATC information system. IEEE Software,13(2):66–76, March 1996.

[5.4] A. Hall. Description of CDIS subset. RODIN/Praxis internal document S.P1286.50.2Issue 0.3, January 2005.

[5.5] C. B. Jones. Systematic software development using VDM. Prentice-Hall, Inc., 2ndedition edition, 1990.

[5.6] C. A. Middelburg. VVSL: a language for structured VDM specifications. Formal Aspectsof Computing, 1:115–135, 1989.

[5.7] J. M. Spivey. The Z Notation: A Reference Manual. Prentice Hall International Series inComputer Science, 2nd edition, 1992.

62

SECTION 6. INITIAL REPORT ON CASE STUDY DEVELOPMENTS FOR CASE STUDY 5: AMBIENT CAMPUS – THE LECTURE

SCENARIO 6.1. Introduction The overall project work on the Ambient Campus case study is focusing on

• elucidation of the specific fault tolerance and modelling techniques appropriate for Ambient Intelligence (AmI) application domain,

• validation of the methodology developed in WP2 and the model checking plug-in for verification based on partial-order reductions, and

• documentation of the experience in the forms of guidelines and fault tolerance templates. More specifically, in this case study we are investigating how to use formal methods combined with advanced fault tolerance techniques in developing highly dependable AmI applications. In particular we are developing modelling and design templates for fault tolerant, adaptable and reconfigurable software. The case study covers the development of several working ambient applications (referred to as scenarios) supporting various educational and research activities. The first year our work has focused on three major subtasks (see Project Description of Work [6.1]):

T1.5.1. Define case study, evaluation plan, measurements and assessment criteria T1.5.2. Produce informal specification of the ambient campus; identify problems related to

provision of fault tolerance T1.5.3. Identify general solutions from the area of application level fault tolerance (such as

atomic actions and exception handling) to be adapted to AmI applications; apply adapted techniques to the ambient campus system.

6.2. Major directions in case study development During the first year we have been mainly working on the first scenario – the Ambient Lecture scenario. This chapter provides a progress report on the Ambient Campus case study, in particular regarding the lecture scenario. After the completion of the requirements document for the Ambient Campus case study [6.2], two strands of work have been carried out. One involves the development of modelling techniques that support rigorous design of the lecture scenario using the B method (see sections 6.3.2 – 6.3.3). The other strand focuses on the feasibility study of the hardware and software that can be used for implementing this system (see sections 6.3.4 – 6.3.5). In the second year, we will work on rigorous specification of this scenario, on its formal modelling using one of the RODIN formalisms (most likely B), on application of the mobility

63

abstractions which are under development in WP2 and on preparation of the second scenario. We are planning to apply the general refinement/decomposition techniques to be developed in WP2 and to progress further with our programming experiments. It is our plan to develop a prototype demonstration to show it during the 4th RODIN workshop in April 2006. Later on, we will develop the second scenario, evaluate the applicability of the process-based modelling techniques (WP2) in this case study and apply the mobility plug-in (WP4) to model-check mobility and fault-tolerance specific properties of the Ambient Campus scenarios. The rest of this chapter discusses in detail the progress that has been made, along with the recommendations for further work to be done. 6.3. Achieved results The first major result is the development of the requirements document written to capture the main characteristics of the system for supporting the lecture scenario of the Ambient Campus case study [6.2]. This system is meant to support mobile devices such as Personal Digital Assistants (PDAs) communicating with each other through wireless network supported by hotspots. The use of wireless network provides a challenge – among others – in the way communications are conducted, where loss of communication might become a common issue. This leads to a requirement for the system to tolerate and handle communication losses appropriately. An overview of the requirements document is given in section 6.3.1. In order to implement the Ambient Campus system, a formal approach for designing the architecture for supporting mobile devices is taken. This design is performed using the B method and through several refinements, the Context-Aware Mobile Agents (CAMA) system specifying the scenario is formulated. More details on this system and its development process are discussed in section 6.3.2. Mobile device potentials are not fully exploited without introducing mobile agents. In our case, a mobile agent is a representation of the human user; it is a piece of software that allows a human user to interact with the services provided on a wireless location through his/her mobile device. Our work on developing the techniques for formal specification of mobile agents and their functionality is summarized in section 6.3.3. Considerable amount of work has also been done on the preliminary exploration of the mobile devices and the underlying technologies that are to be used in the lecture scenario. These include the hardware (such as PDAs and hotspots) as well as the software (such as the middleware for supporting mobile agents, programming language and platform support) that are needed for the implementation and the demonstration of the lecture scenario. Sections 6.3.4 and 6.3.5 cover the hardware and software technologies respectively. 6.3.1. Requirements document Based on the methodological approach outlined by J.-R. Abrial [6.3], we prepared a

64

requirements document for the Ambient Campus case study. This document focuses on the lecture scenario. In particular, we introduce Ambient Campus Environment (ACE) concept to cover entities that are needed to support the running of the lecture scenario. These include the PDAs, desktop computers, software agents (to be run on the PDAs and desktop computers), as well as hotspots to enable wireless communication among the software agents. For better understanding and clarity, the requirements are classified into several categories. The taxonomy of the lecture scenario requirements is as follows: 1. EN – this requirement covers general requirements regarding the environment, including

statements on the required properties of users and ACE.

2. FT – this requirement deals with fault tolerance issues: the system should be able to tolerate a number of abnormal situations such as connectivity loss, failures of PDAs and desktop computers, violation of time constraints and fire alarms. These requirements define a set of related abnormal situations.

3. ST – the requirement of this category specifies the states that an agent can fall into, and how the agents change their states depending on the role or activity they are performing at a particular time.

4. SV – this requirement defines service requirements and restrictions that ACE should provide.

5. QL – the QL requirement sets additional requirements related to the quality of service, such as performance and resource usage that certain services provided by the agents need to satisfy.

6. SE – this requirement captures issues related to security, such as access permission, authorization and shared resource access.

7. TT – the requirement of this category lists the delays and timeouts associated with various

services or service quality requirements. Using this taxonomy, the full requirements were constructed; readers are recommended to consult [6.2] for a thorough description and full explanation of these requirements. In this section, we show some important excerpts from the requirements document. 6.3.1.1. Location and connectivity Location refers to a room on campus that has a hotspot providing wireless connectivity. Connectivity area may reach beyond the room or even cover several rooms. Connectivity areas may also overlap (Figure 6.1). The users (i.e. people) involved in the scenario are teachers and students. There is one teacher and several students involved in each lecture activity. Teacher and student users are represented by software agents in the ACE: the teacher agent is run on the desktop computer present in the

65

room whereas each student agent is run on an individual PDA (see Figure 6.2). The users control the actions of their agents through a graphical user interface presented on their device (desktop computer or PDAs). When a student carrying a PDA moves from one location to another, there is a possibility that his/her agent will experience a loss of connection, and re-connection later (see Figure 6.1). This should be handled appropriately by the system. 6.3.1.2. Possible lecture activities One of the most important aspects of the scenario is the representation of the activities that can be performed during a lecture. Typical activities might include:

• Registration of students At the beginning of a lecture, the teacher takes attendance of the students. Students register to the lecture through their PDA, and there is an authentication process to ensure that only authorised students will be allowed to participate in the ACE-supported lecture scenario.

• Material dissemination Teacher can distribute lecture related materials, such as lecture notes, reading list or timetable/venue changes directly to students’ PDAs.

• Organisation of students into groups Students may be organised into groups to do a group task or to allow group discussions. Enforcement of group policies (such as only those within the same group can talk to each other) will be observed in the scenario.

• Individual task From time to time, teacher may give students a task to do individually. This includes those tasks for assessing the progress of each student, so we need to ensure that the submissions from the students are handled appropriately.

• Group task The teacher may also give tasks to be performed through collaborative effort by students in groups. As with the individual tasks, the submission of the group tasks must be handled appropriately.

Figure 6.1: Location and connectivity area

66

• Questions from students Students might be more inclined to ask questions on materials they do not understand if they can do it quietly through their PDA. The teacher can then answer the questions privately or if he/she thinks it will benefit the whole class, the answer can be broadcast to all. The teacher could also pass the questions to the class to see if any of the students can provide an answer.

More activities can possibly be added later, but for now we think the above set should provide enough challenge for developing and testing the software system to support the lecture scenario. The requirements document also addresses emergency, failure and timing requirements, these can be found in [6.2]. The following sections discuss the framework and infrastructure for implementing the Ambient Campus case study. 6.3.2. CAMA system The Context-Aware Mobile Agents (CAMA) system consists of a set of locations and basic coordination functionality provided by the middleware. Active entities of the system are agents.

TA

SA

SA

SA

SASA

SA

SASA

SA

SA

SA

SASA

SA

SA

Wireless Connectivity Area

Desktop computer

PDA

TA Teacher Agent

SA Student Agent

Figure 6.2: Arrangement of Ambient Campus Environment

67

An agent is a piece of software that conforms to some formal specification. The requirements for agents are developed using the B Method. Each agent is executed on its own platform. The platform provides an execution environment and an interface to the location middleware. Agents coordinate their execution through a Linda-type coordination tuple space to ensure their asynchrony and anonymity. More specifically, they communicate through the special construct of the coordination space called scope, which structures their coordination. An agent can cooperate only with other agents through participation in a common scope. Agents can logically and physically migrate from a location to another location. Migration from a platform to a platform is also possible using logical mobility. An agent is built as a combination of one or more roles. Each role is a formal specification of a specific functionality so that a composition of specifications of all the roles forms the specification of the agent. Each role is a result of the decomposition of an abstract scope model so that each concrete run-time scope is an instantiation of an abstract scope model. 6.3.2.1. Formal development of CAMA system The formal development process of the CAMA system consists of several steps. First, we create abstract specifications of the middleware (location) and the scopes to be supported by the system. Then we develop (by the stepwise refinement method) specifications of different roles participating in scopes. Finally, we compose an agent specification as a combination of several developed roles (i.e. agent interfaces) and the default functionality defining the agent behaviour outside scopes. Agent specification can be further refined by adding more details and custom functionality. Communication compatibility of different agents is ensured by the fact that all agents are developed by the formal refinement method from the same abstract specifications of different roles and the middleware. Therefore, agents can collaborate making safe assumptions about the functionality of their peers. The B Method [6.3] (further referred to as B) is an approach for the industrial development of highly dependable software. The method has been successfully used in the development of several complex real-life applications. The tool support available for B provides us with the assistance for the entire development process. For instance, Atelier B [6.4], one of the tools supporting the B Method, has facilities for automatic verification and code generation as well as documentation, project management and prototyping. The high degree of automation in verifying correctness improves scalability of B, speeds up development and, also, requires less mathematical training from the users. The development methodology adopted by B is based on stepwise refinement. While developing a system by refinement, we start from an abstract formal specification and transform it into an implementable program by a number of correctness preserving steps, called refinements. A formal specification is a mathematical model of the required behaviour of a (part of a) system. In B, a specification is represented by a set of modules, called abstract machines. An abstract machine encapsulates state and operations of the specification and as a concept is similar to a module or a package.

68

We have started some initial work on application of the model-checking mechanisms to verification of agent properties. In particular, we are interested in the behaviour of communicating multi-agent systems, including their fault tolerant aspects. For this purpose, we are developing the CAMA semantics and multi-stage translation process from CAMA to Petri nets. This work is carried out as a joint activity between WP4 work on mobility plug-in and WP1. In our approach [6.5], Klaim process algebra [6.6] and pi-calculus will be employed for the intermediate representation and transformation into Petri nets. The model checking technique adopted in our work is a partial-order model-checking based on Petri net unfoldings. 6.3.3. Mobile agent development In our approach, an agent specification is built by extending one or more roles obtained formally through decomposition of the abstract scope models. The refinement step introduces a specification of the minimal agent functionality called the default role. This functionally permits an agent to talk to locations, create/join/leave scopes, and do migration. Agent may also need some logic that glues independent interfaces and allows them to talk to each other. This is done via global agent variables and the special methods for accessing them. Upon its completion, the agent specification is used to build the source code for the actual agent program. The source is linked with the middleware library to get an executable agent program. The generated agent source may run on PDAs, laptops, desktop PCs and smart-phones using the platform-specific middleware implementation as the adaptation layer. The standard work cycle of an agent looks like this: an agent detects the available locations and connects to at least one of them, then it looks for the current activities on the location(s) or creates its own new scope, and finally it joins a scope and plays one of the implemented roles in it. Only when the agent decides to play a particular role in a scope, it really starts to cooperate with other agents. The agents are interoperable and able to understand each other because the role functionalities of all scope participants are based on the same abstract model. As a result, the composition of agent functionalities in a scope corresponds to the initial abstract model. 6.3.4. Mobile technology: hardware Before we can develop any software agents, we need to familiarise ourselves with mobile technologies, including the hardware. This led to the purchase of several PDAs and a pair of wireless hotspots. The PDAs must have features for supporting wireless connection and they must be able to run Java programs. In the end we decided to purchase four HP-IPAQ hx2750 running Microsoft Windows Pocket PC 2003. This model is near the top of the range line at the time. We could in theory just “piggy back” on the wireless network provided by the School of Computing Science at the University of Newcastle through their hotspots, but we would like to experiment with different configurations of wireless hotspots. One configuration is where the hotspot is connected to just the desktop computer present at a location; another is where the hotspot is connected to the campus wide network.

69

We also obtained a pretty basic desktop computer on which we installed Linux operating system. This computer hosts the middleware (i.e. the location or tuple server) needed to coordinate the communication among software agents. A similar installation in the lecture scenario will also be used by teachers to deliver lecture, i.e. it will serve as a platform for hosting the teacher agent. 6.3.5. Mobile technology: software We need customised software to provide the infrastructure for ACE such as the tuple space server (middleware), as well as the agent software to run on the PDAs. 6.3.5.1. Architectural comparison For the middleware, we are using the asymmetric scheme which is closer to the traditional service provision architectures. This scheme is based on the concept of a fairly reliable infrastructure-provided wireless connectivity. The alternative symmetric scheme can also operate in ad-hoc networks and all the coordination functionality is implemented by the agents. In our scheme the larger part of the coordination and controlling logic is moved to a location server. This approach can support large-scale mobile agent networks in a very predictable and reliable manner. It makes the better use of the available resources since most of the operations are executed locally. Moreover, the asymmetric architecture eliminates the need for complex distributed algorithms or any kind of transactions. This allows us to guarantee atomicity of certain operations without sacrificing performance and usability. The scheme also provides a natural way of introducing context-aware computing where a location is part of an agent context. The major drawback of the asymmetric scheme is that an infrastructure support is always required for mobile agents to collaborate. 6.3.5.2. Middleware: location/tuple server After the initial experiments with several mobile agents middleware systems [6.6][6.7][6.8], we decided to start the development of our own mobile agents middleware. The major rationale for this decision is that all these systems implement ad-hoc style communication which we found to be too heavy-weight for the available hardware. Another problem is the lack of industrial strength implementations of ad-hoc routing algorithms. Our approach is based on the location-based architecture where all the coordination in a location happens inside a single coordination server. This allows us to achieve better performance and enrich the concept of coordination space with structuring, exception handling and security features. 6.3.5.3. Java platform for PDAs The software agents are to be written in Java. In order to run Java applications on the PDAs, we need to first install Java Virtual Machine (JVM) on them. We investigated several JVMs that are available for Pocket PC 2003. There are not many such JVM available, we tried (the demo version in the case of those commercial ones) and compared several of them:

70

• eWe from Ewesoft [6.9] eWe is a reasonably well-developed and freely available JVM, but it does not have standard Java libraries, therefore there are some important features missing (such as “serialization”).

• J9 from IBM [6.10] This JVM supports standard Java libraries bar several (for example, swing) and available to purchase for a reasonable price.

• CrEme from NSIcom [6.11] This is one of the most comprehensive JVMs for PDA, but on the down side, it is very expensive to purchase.

We decided to use IBM’s J9 to provide Java platform on our PDAs. J9 is chosen because it supports all the necessary features that we intend to use for our software agent development and it is not too expensive to purchase ($5.99 per license). 6.3.5.4. Example We have developed a simple system to demonstrate the feasibility of ambient applications using tuple space and PDAs where the communication is done through a wireless network. This system allows students and a teacher to perform text-based chatting; in this application, the students use their PDA, and the teacher uses a desktop computer, which also hosts the tuple space server. The Java implementation can be divided into two main parts:

• jcama library providing classes for dealing with tuple space through CAMA architecture (see section 6.3.2). At the moment, only basic in and out operations are supported, allowing objects (such as strings, numbers and even binaries) to be placed into and taken out of the tuple space. The final version will provide all the communication primitives along with the scoping mechanism, exception handling and migration. We are also planning to port the client-side middleware to other platforms and languages, such as Symbian smartphones, .NET and Python.

• Graphical User Interface (GUI)-based agents. There are two types of agents: student and teacher agents.

o The student agent allows student to type in a message and to send it to the tuple space. This agent also checks the tuple space for any message addressed to it and displays this message on the PDA (as chat history) when that happens.

o The teacher agent manages the tuple space. It picks up any message sent to the tuple space and broadcasts it to all agents present at that time. Teacher agent can send messages as well. It also keeps a record of all student agents currently present, along with the chat history.

In the client-server terminology, the student agent can be considered to be the client whereas the teacher agent, the server.

There can only be one teacher agent running at a given time, but there can be multiple student agents. Each student agent has a unique identifier, which enables the teacher agent to distinguish

71

them. When a student agent is run, it tries to detect if there is a teacher agent present. If that is the case, the student agent will join the chat session. If there is no teacher agent running, the student agent cannot send any message to the tuple space. When a teacher agent is activated, it detects any student agents currently running and automatically makes them join the chat session. Agents can join or leave a session at any time; the system provides the functionality to handle these events accordingly. Screenshots of this system are given below. To obtain these screenshots, all of the agents were run on a desktop computer, but in practice, student agents are usually run on PDAs. Since these agents are written in Java, they can be easily ported on various platforms or devices. Teacher runs his/her agent, and when students run theirs, they will be automatically added into the session and they will receive a welcome message. Teacher agent lets the teacher know who just joined the session (see Figure 6.3). Student agents can join at anytime, as long as the teacher agent is running.

Figure 6.3: Initiation of the chat session Teacher and students can then exchange messages through their agents, as can be seen in Figure 6.4. This screen capture also shows that one student (“Bob”) is about to leave the chat session by invoking the “Quit” action. When this happens, teacher agent will display a message to let the teacher know that a student had just left the chat session, but other students will not know, and the session just continues (Figure 6.5). It is pretty straightforward to modify the system so that all agents will be notified if anyone leaves. When the teacher agent leaves the session, the chat session is terminated. There is nothing else that the student agents can do apart from leaving (quitting) the session, unless the teacher agent comes back and rejoins, upon which the chat can be resumed.

72

Figure 6.4: Sending and receiving messages during the chat session

Figure 6.5: One student agent left the session, but the chat continues This system works well and the idea of using a tuple space enables the system to handle loss of connection from the PDAs. When these PDAs manage to re-establish the connection, their agents automatically retrieve all messages sent to the tuple space while they were disconnected, hence no communication should be lost.

73

6.4. Setting the demonstrations Ambient Campus is the only case study within the RODIN project that aims to provide (a set of) demonstrations. At this stage, we are planning a simple demonstration to be shown during the 4th Plenary Workshop in April 2006. 6.5. Future development It is our plan to complete the development of the first prototype of the system supporting lecture scenario by summer 2006. Upon this completion, we will test the system, evaluate its development process and feedback our experience to work conducted in WP2-WP4. During the coming 8 months we will finalise our decision about the next scenarios. The lecture scenario could be followed by one of the following Ambient Campus scenarios: a library-based scenario or a medical school-based scenario. The library scenario places mobile devices into the core of activities performed in libraries. The system to be developed should enable library users to search and locate library materials on the move, to scan texts or images directly to their mobile device, to transfer collected data to their desktop computers, and to directly search and download materials from the web as they found a reference to it in a library material. The medical scenario would involve the Medical Education School of the University of Newcastle upon Tyne which plans to equip all first year students of the Medical Faculty with PDAs from 2006. With the help of these PDAs, the students will be able to perform a number of education activities when they are located in one of the university campuses. We are particularly interested in supporting distributed work of groups of students on joint presentations, essays, course work as well as in supporting discussion groups and questions and answers sessions which follow lectures and involve both lectures and students. There is also a possible link with Nokia case study on developing formal technique within MDA context (CS3). Later in the project we will analyse how to enrich the MITA framework with the abstractions and fault tolerance solutions we are developing for this case study and if this is possible, we will investigate further how the framework can be applied in developing this case study. Another possible future development – the usefulness of which we will evaluate later in the project – is the design and implementation of the ambient campus system on other mobile platforms such as smart-phones and laptops. 6.6. Summary This section outlined the progress made during the first year of the Ambient Campus case study. The major results include the completion of the requirements document; the development of the infrastructure for supporting Ambient Campus system using the B method; the exploratory research on the mobile technologies; and the implementation of a simple example demonstrating our ability to develop ambient applications. There is still a lot of work to be done, including further refinement of the ambient infrastructure

74

and the implementation of a fully featured demonstration software system. Based on the progress that we have made so far, we expect that we will be able to meet the challenging objectives set for this case study in the remaining two years. 6.7. Acknowledgements We are grateful to Jean-Raymond Abrial for his insightful comments on the initial version of the Ambient Campus requirements document. 6.8. References [6.1] Rigorous Open Development Environment for Complex Systems (RODIN), Description

of Work, IST 6th Framework Programme, Proposal No. 511599, April 2004. [6.2] RODIN Deliverable D4 – Traceable Requirements Document for Case Studies, Project

IST-5111599, February 2005. [6.3] J.-R. Abrial. The B-Book. Cambridge University Press, 1996. [6.4] Atelier B, available from http://www.atelierb.societe.com/index_uk.html. [6.5] A. Iliasov, V. Khomenko, M. Koutny and A. Romanovsky. On Specification and

Verification of Location-based Fault Tolerant Mobile Systems. In Proc. REFT'05 - Workshop on Rigorous Engineering of Fault Tolerant Systems, Newcastle upon Tyne (UK), Technical report, University of Newcastle upon Tyne, UK, July 2005.

[6.6] R. De Nicola, G. Ferrari, R. Pugliese. Klaim: a Kernel Language for Agents Interaction and Mobility. IEEE Transactions on Software Engineering, 24(5):315-330, IEEE Computer Society, 1998.

[6.7] G. P. Picco, A. L. Murphy, G.-C. Roman. Lime: Linda Meets Mobility. Proc of the 21st Int. Conference on Software Engineering (ICSE'99), Los Angeles (USA), May 1999.

[6.8] G. Cabri, L. Leonardi, F. Zambonelli. MARS: A Programmable Coordination Architecture for Mobile Agents. IEEE Internet Computing, 4(4):26-35, July 2000.

[6.9] Ewe programming system, available from http://www.ewesoft.com. [6.10] IBM’s J9, available from http://www.handango.com. [6.11] CrEme, available from http://www.nsicom.com.

75

initial report on case study ... - newcastle...

Documents