از مطالب بیان شده می­توان به ضرورت مدیریت خطاهای ناپایدار و متناوب پی برد. در واقع سیستم باید با بهره گرفتن از تکنیک­های کشف و مکان­ یابی خطا، Master Nodeی را که دارای خطای گذراست شناسایی کند. از آنجا که مدیریت خطا توسط گره­های بالایی انجام می­گیرد، پس Mobile Node تکنیک­های کشف و مکان­ یابی خطای گذرا را اجرا می­ کند. بعد از تشخیص وجود خطای گذرا در Master Node، تمامی Body Nodeهای Master Node معیوب باید از وجود خطای گذرا مطلع شوند. همچنین در شبکه ­های چند Master Nodeی، این Body Nodeها باید به یک Master Node سالم تخصیص یابند و در صورت نبود Master Node سالم در شبکه، Body Nodeها خود موظف به ارسال اطلاعات برای Master Node مجازی تعبیه شده در Mobile Nodeمی­باشند. این در حالیست که در شبکه ­های تک Master Nodeی، خود Body Nodeها به صورت مستقیم اطلاعاتشان را به Master Node مجازی ارسال می­ کنند. این فرایند تا زمان برطرف شدن خطای گذرای Master Node معیوب ادامه پیدا می­ کند. به محض برطرف شدن خطای گذرا، باید Body Nodeها را از سالم شدن Master Node آگاه کرد و بعد آنها را به Master Node سالم شده، تخصیص داد.

بعد از طراحی و پیاده­سازی Master Node باید با بهره گرفتن از تکنیک­های پیش ­بینی خطا، خطاهای پایدار و گذرا که امکان وقوع دارند، شناسایی شوند. سپس با بهره گرفتن از تکنیک­های تزریق خطا آنرا به سیستم تزریق کرد تا میزان تحمل خطای Master Nodeها مشخص شود. همچنین با این کار می­توان کاستی­های موجود را برطرف کرد و یا از حضور Master Nodeها در وضعیت­هایی که باعث بروز خطاهای گذرا می­ شود، جلوگیری کرد.
۳-۳-۳ طراحی ارگونومی
ارگونومیک^[۶۹]، علمی است که بر روی سادگی استفاده از ماشین مانور می­دهد. این علم با تمرکز بر روی ویژگی­های طراحی، خلاء بین کاربر و محصولات را پر می­ کند. طراحی ارگونومی با طوفان مغزی^[۷۰] همراه است. فرایند طوفان مغزی، مرحله­ ای است که در آن افراد مختلف با تخصص­های مختلف گرد هم جمع می­شوند و راه­ حل­های مناسبی را برای حل یک مشکل ارائه می­ دهند.
با مجتمع کردن ارگونومی در دستگاه­های پوشیدنی می­توان یک ارتباط دوستانه را بین کاربر و این کامپیوترها بوجود آورد. در فرایند طراحی ارگونومی برای کامپیوترهای پوشیدنی باید سه فاکتور مهم یعنی «کاربر»، «کامپیوتر پوشیدنی» و «وظیفه­ی کامپیوتر پوشیدنی» را در نظر گرفت.
در بحث «کاربر»، باید فاکتورهای مختلفی از جمله سن کاربر، جنسیت کاربر، توانایی فیزیکی کاربر و غیره، مورد توجه قرار گیرند. برای مثال Body Node را می­توان به صورت یک مچ­بند طراحی کرد. کاربر استفاده کننده از این مچ­بند می ­تواند یک نوزاد ۶ ماهه یا یک جوان ۲۵ ساله باشد. طراحی ارگونومی با در نظر گرفتن سن کاربر، تأکید می­ کند که مچ­بند نوزاد باید بگونه­ای طراحی شود که سبک وزن و کوچک باشد.
در طراحی ارگونومی، فاکتور «کامپیوتر پوشیدنی» بر روی ویژگی­های مختلفی از جمله اندازه و شکل تأکید می­ کند. برای مثال بدون در نظر گرفتن طراحی ارگونومی، می­توان شکل ظاهری Master Node را مانند یک چاقوی کوچک بسیار زیبا طراحی کرد. با توجه به اینکه Master Node بر روی بدن کاربر پوشیده می­ شود، هر لحظه این امکان وجود دارد که به بدن کاربر آسیب رساند.
در نظر گرفتن فاکتور «وظیفه­ی کامپیوتر پوشیدنی»، در طراحی ارگونومی امری ضروری می­باشد. برای مثال با در نظر گرفتن این فاکتور در طراحی ارگونومی، یک Body Node که وظیفه­ اش کنترل نبض کاربر است را نمی­ توان به صورت گوشواره طراحی و بر روی گوش نصب کرد.
۳-۳-۴ تحمل خطای شفاف
در بحث تحمل خطا همواره مسئله­ شفافیت باید مورد توجه قرار گیرد. تحمل خطای شفاف یعنی اینکه اقدامات و تکنیک­هایی که در زمینه­ تحمل خطا انجام می­گیرند، از دید کاربر (فرد تحت نظارت) مخفی باشند. در ادامه با بیان یک سناریو لزوم تحمل خطای شفاف بیان می­ شود. حالتی را می­توان تصور کرد که، پیاده­سازی Body Nodeها و Master Nodeها بگونه­ای باشد که هر کدام از آنها حاوی یک لامپ کوچک باشند. به محض کشف خطای پایدار یا ناپایدار در هر ماژول، لامپ آن گره شروع به چشمک زدن می­ کند.
در نگاه اول ممکن است ایده­ استفاده از لامپ­های چشمک زن ایده­آل به نظر برسد. زیرا فرد تحت کنترل، به محض آگاهی از وجود خطا، سعی در برطرف سازی آن می­ کند. اما این ایده به دو دلیل رد می­ شود. اولاً، افراد تحت کنترل مانند سالمندان معمولاً دانش تخصصی کافی را برای برطرف­سازی خطاها ندارند. ثانیاً، مبحث شفافیت در این ایده در نظر گرفته نشده است. بگونه­ای که این هشدار استرس شدیدی را به فرد تحت نظارت وارد می­ کند و ممکن است سلامتی روحی و روانی او را به مخاطره بیاندازد. این در حالی است که ممکن بود خطا فوق گذرا باشد و خللی در کارکرد شبکه ایجاد نمی­کرد و پس از مدتی برطرف می­شد. به بیانی این خطای گذرا توسط مدیریت خوشبینانه قابل مدیریت بود.
به عنوان یک نتیجه ­گیری کلی باید خاطرنشان کرد که به دلیل ساده بودن سخت­افزار Body Node و Master Node و نداشتن امکاناتی از قبیل نمایشگر، عدم در نظر گرفتن شفافیت می ­تواند مشکلات روحی و روانی فراوانی را برای فرد تحت نظارت به همراه داشته باشد. لذا اگر بنا باشد برای Body Nodeها و Master Nodeها، خطاهایی از قبیل شارژ باتری را به کاربر هشدار داد؛ باید این هشدار توسط Mobile Node به کاربر داده شود.
۳-۳-۵ مدیریت خطا در معماری سه لایه­ای ارائه شده
در معماری سه لایه­ای ارائه شده، مبحث مدیریت خطا یکی از مباحث بنیادی است. لازم به یادآوری است که فلسفه­ی طراحی Body Nodeها و Master Nodeها بر روی سادگی و پیچیده نبودن مانور می­دهد. به بیانی گره­های پوشیدنی مذبور فاقد عناصر هشدار خطا از جمله نمایشگر و لامپ می­باشند. لذا با توجه به مطالب بیان شده و با در نظر گرفتن شفافیت، هشدار خطای Body Nodeها و Master Nodeها از طریق گره Mobile Node انجام می­گیرد. به بیانی دقیق­تر در گره­های پوشیدنی، تشخیص و کشف خطای هر گره به وسیله­ خود گره مشخص می­ شود. سپس گره خطای خود را به گره بالایی که Mobile Node است، اطلاع می­دهد. در پایان با در نظر گرفتن بحث شفافیت اگر نیاز باشد که کاربر از این خرابی مطلع شود، این آگاه­سازی از طریق گره Mobile Node صورت می­گیرد.
برای درک بهتر در ادامه از دو مثال استفاده می­ شود. مثال اول بدین صورت است که یک Body Node، دارای یک سنسور افزونه و یک سنسور فعال است. حالتی را می­توان تصور کرد که تمامی سنسورهای این Body Node به سبب خطای پایدار از کار بیافتند. در این حالت خود Body Node، خطا و خرابی سنسورهایش را کشف می­ کند؛ سپس با ارسال پیامی، Mobile Node را از این خرابی آگاه می­ کند. در پایان Mobile Node، به Master Node آن گره­ها فرمان می­دهد تا Body Node معیوب را خاموش و حالت Body Node افزونه­ی آن را از حالت standby به حالت فعال تغییر دهد.
مثال دوم بدین شرح می­باشد که باتری Master Node فیزیکی از حد آستانه پایین­تر باشد. در اینصورت خود Master Node، خطای باتریش را کشف می­ کند و با ارسال پیامی Mobile Node را از این خرابی آگاه می­سازد. بلافاصله در این شرایط، Mobile Node با یک پیام متنی به کاربر هشدار شارژ باتری Master Node را می­دهد و همزمان به Body Nodeهای Master Node معیوب فرمان می­دهد تا اطلاعاتشان را برای Master Node مجازی ارسال کنند.
به عنوان یک نتیجه ­گیری کلی باید بیان کرد که مدیریت خطا در معماری ارائه شده به صورت سلسله مراتبی است. بدین صورت که پیام­ها از گره­های پایینی به گره­های بالایی می­روند و فرمان­ها از گره­های بالایی به گره­های پایینی می­آیند. این بدین معنی است که هرگز گره پایینی فرمانی را به گره بالایی نمی­دهد.
۳-۳-۶ Mobile Nodeها
امروزه دستگاه­های Mobile Node به سرعت در حال پیشرفت هستند، این امر باعث شده است که محدودیت­های دستگاه موبایل نسبت به کامپیوترهای پوشیدنی بسیار کمتر باشد. از اینرو دستگاه­های موبایل دارای نرم­افزار و سخت­افزار پیچیده­تری می­باشند، بگونه­ای که آنها قادر به انجام پردازش­های سنگین و همچنین توانایی پشتیبانی از برنامه­ ها و نرم­افزارهای پیچیده را دارند. لذا این گره­ها بحث­های مدیریت داده ­ها را به صورتی عالی انجام می­ دهند و به نحوی شایسته با ابر ارتباط برقرار می­ کنند.
لازم به ذکر است که دستگاه موبایل می ­تواند هر کامپیوتر سیاری از قبیل یک PDA، گوشی موبایل، تبلت، لپ­تاپ و … باشد. یعنی دستگاه موبایل می ­تواند یک گوشی ساده­ی موبایل باشد که حتی امکاناتی از قبیل بلوتوث، پشتیبانی از اینترنت و نصب برنامه­ ها و نرم­افزارهایی که برای ارتباط با کامپیوترهای پوشیدنی و ابر است را نداشته باشد. همچنین یک دستگاه موبایل می ­تواند یک لپ­تاپ پیشرفته باشد که چندین تکنولوژی ارتباطی، CPU قدرتمند، چندین ترابایت حافظه و قابلیت پشتیبانی از نرم­افزارهای پیشرفته را دارد.
با توجه به مطالب بیان شده، معماری سه لایه­ای پیشنهادی از چالش­هایی رنج می­برد. از آنجا که دستگاه­های موبایل رابط ارتباط بین کامپیوترهای پوشیدنی و ابر هستند، نقش و عملکردشان نیاز به بررسی دقیق­تری دارد. برای مثال اگر در لایه­ی دوم معماری پیشنهادی، از یک گوشی موبایل ساده که فاقد هرگونه تکنولوژی ارتباطی و فاقد قابلیت نصب نرم­افزار است، استفاده شود، آنگاه لایه­ی دوم قادر به انجام وظایفش نیست. همچنین می­توان حالتی را تصور کرد که در لایه­ی دوم، یک لپ­تاپ پیشرفته مورد استفاده قرار بگیرد. در نگاه اول به نظر می­رسد که این لپ­تاپ پیشرفته بهترین گزینه برای لایه­ی دو می­باشد اما اینگونه نیست. اولاً چنین دستگاهی گران است و همچنین دستگاه لایه­ی دو همیشه باید در حالت روشن یا آماده­باش باشد، این در حالیست که اگر لپ­تاپ فوق را بخواهیم در حالت روشن نگه داریم، در طی مدت زمان محدودی شارژ باتریش به اتمام می­رسد. به علاوه، لپ­تاپ قابل حمل نیست زیرا نسبت به گوشی موبایل سنگین­تر است به گونه ­ای که افراد تحت نظارت، بخصوص افراد بیمار و سالمند قادر به تحمل وزن این دستگاه برای مدت طولانی نیستند.
نتیجتاً، در انتخاب دستگاه مناسب برای لایه­ی دو باید دقت شود. دستگاه سیارِ انتخابی باید توانایی پشتیبانی از تکنولوژی­های ارتباطی مختلف را داشته باشد و قابلیت نصب و پشتیبانی از نرم­افزار ارتباطی بین لایه­ های اول و سوم را داشته باشد. همچنین این دستگاه نباید گران و سنگین باشد، به گونه ­ای که تمامی اقشار جامعه و نیز افراد با سنین مختلف قادر به تهیه و استفاده از آن باشند.
خطا­های سخت­افزار: سخت­افزار Mobile Nodeها به مراتب نسبت به Body Node­ها و Master Nodeها از تهدیدات و خطرات کمتری رنج می­برند. اما هر لحظه این امکان وجود دارد که گره Mobile Node به سبب خطای پایدار خراب شود، بگونه­ای که قادر به ادامه­ انجام فعالیتش نباشد. لازم به ذکر است که خرابی فرستنده، گیرنده و باتری Mobile Node و همچنین خالی شدن باتری آن، منجر به وقوع خطای پایدار در این گره می­ شود. در این حالت استفاده از یک Mobile Node افزونه اولین راه­حلی است که به ذهن می­رسد. اما واقعیت امر این است که هزینه­ Mobile Nodeها گران است، لذا استفاده از واحد رزرو برای Mobile Node با تحمل هزینه همراه است. به بیانی استفاده از واحد افزونه و تعداد واحدهای افزونه بستگی به کاربرد دارد، به طور مثال اگر کاربرد حساس باشد می­توان با تحمل هزینه مالی از ۱۰ عدد واحد رزرو استفاده کرد.
اگر گره Mobile Node به سبب خطای پایدار خراب شود آنگاه انتقال اطلاعات از Master Node به ابر معنی ندارد. زیرا Master Node فاقد نمایشگر می­باشد و به اندازه­ Mobile Node امکانات ارتباطی و نرم­افزاری ندارد، پس در این حالت Master Node به عنوان یک هشدار دهنده عمل می­ کند. Master Node هشدار خرابی Mobile Node را برای مرکز ابری ارسال می­ کند، همچنین با در نظر گرفتن شفافیت، توسط بلوتوث یک پیام متنی را به تمامی Mobile Nodeهایی که در اطراف شخص تحت نظارت قرار دارند، ارسال می­ کند. در واقع این پیام، هشدار جایگزینی یا تعمیر Mobile Node را می­دهد. بعد از این هشدار، در صورت موجود بودن واحد رزرو، می­توان از آن استفاده کرد. شایان ذکر است که با خراب شدن واحد افزونه، این چرخه دوباره ادامه پیدا می­ کند.
از مطالب بیان شده می­توان به این نتیجه رسید که با خراب شدن Mobile Node باید Master Nodeها به منظور هشدار دادن، بلافاصله از این خرابی آگاه شوند. همچنین برای اینکه گره Master Node بتواند از وضعیت گره Mobile Node خبردار شود، در زمان­های خاصی نیاز به برقراری ارتباط با این گره را دارد. به طور مثال گره Mobile Node می ­تواند هر ۱۰۰ ثانیه یکبار، پیام «سلام Master Node» را برای Master Node ارسال کند، که عدم دریافت این پیام از سوی Master Nodeها، نشانه­ی خراب بودن Mobile Node است. که این مسئله در بخش­های قبلی به صورت مفصل مورد بررسی قرار گرفت.
سناریویی را می­توان تصور کرد که گره Mobile Node سالم و بی­نقص باشد و گیرنده Master Node مشکل داشته باشد. ممکن است این امر باعث شود که Master Node به اشتباه تشخیص دهد Mobile Node خراب است، بگونه­ای که اقدام به ارسال هشدار اشتباهی برای ابر کند.
در شبکه ­های چند Master Nodeی، به منظور برطرف­سازی مشکل فوق می­توان از تکنیک رأی­گیری استفاده کرد. بدین صورت که برای انجام فرایند رأی­گیری تعداد Master Nodeهای فیزیکی فرد باشند. روش کار بدین صورت است که از روش رأی­گیری بر اساس رأی اکثریت استفاده می­ شود. یعنی اکثریت Master Nodeها با هم سالم بودن یا نقص داشتن Mobile Node را مشخص می­ کنند. نتیجتاً در شبکه ­های چند Master Nodeی، می­توان مشکل سناریوی بالا را با بهره گرفتن از تکنیک رأی­گیری حل کرد.
ممکن است با بررسی سناریوی بالا این سؤال مطرح شود که در شبکه ­های تک Master Nodeی اگر گیرنده­ی Master Node دچار مشکل شود، تکلیف چیست؟ به منظور پاسخ به سؤال فوق در تحقیق حاضر الگوریتمی تحت عنوان «شناسایی گیرنده کَر» مطرح می­ شود. در الگوریتم مذبور اگر گیرنده Master Node برای مدت زمان مشخصی به کانال­های بین خودش و Body Node و Mobile Node گوش کند و چیزی را نشنود، آنگاه این چنین تشخیص داده می­ شود که گیرنده­ی Master Node کر است. عملکرد الگوریتم «شناسایی گیرنده کر» به شرح زیر است.

1. 1. در بازه زمانی X به لینک بین Master Node و Mobile Node گوش کن، اگر پیام «سلامMaster Node» را از Mobile Node دریافت نکردی، به مرحله ۲ برو، در غیر اینصورت از الگوریتم خارج شو (X دو برابر فاصله زمانی است که Mobile Node پیام­هایش را در شبکه پخش می­ کند).

1. 1. از این لحظه تا زمان Y، اگر پیام­های «سلام ارباب» را از سوی Body Nodeها دریافت نکردی یا داده­هایی را از Body Nodeها دریافت نکردی به مرحله ۳ برو، در غیر این صورت به مرحله ۴ برو.

1. 1. گیرنده اصلی Master Node خراب است، تا ابد آنرا خاموش و گیرنده standby، را تا ابد روشن کن، سپس به مرحله یک برو.

1. 1. یک پیام هشدار مبنی بر خراب بودن Mobile Node، برای ابر و موبایل­های اطراف ارسال کن.

باتری: خوشبختانه شرکت­های سازنده­ی Mobile Nodeها امروزه به نوع باتری محصولاتشان توجه ویژه­ای دارند. بگونه­ای که این باتری­ها با داشتن حجم کم می­توانند برای ساعت­های طولانی انرژی لازم را در خود ذخیره کنند. علاوه بر مزایای فوق باید خاطرنشان کرد که باتری­های Mobile Nodeها قابل شارژ می­باشند، همچنین در صورت خرابی باتری، می­توان آن را به سادگی تعویض کرد.
تکنولوژی ارتباطی: با توسعه و پیشرفت Mobile Nodeها، آنها قادر به پشتیبانی از انواع مختلف تکنولوژی­های ارتباطی می­باشند. همچنین کارخانه­های سازنده­ی این دستگاه­ها، معمولاً چندین نوع مختلف از تکنولوژی­های ارتباطی را به صورت همزمان در یک Mobile Node تعبیه می­ کنند. لذا مباحثی که در بحث انتخاب تکنولوژی ارتباطی وجود دارند از قبیل میزان مصرف باتری، برد انتقال اطلاعات، روش کشف خطا در تکنولوژی ارتباطی و حجم ماژول، دیگر برای Mobile Nodeها نگران کننده نیست، زیرا کارخانه­های سازنده این مسائل را در طراحی و پیاده­سازی به خوبی مد نظر قرار داده­اند بطوریکه کاربر می ­تواند با توجه به شرایط، مناسب­ترین تکنولوژی را انتخاب کند.
اما دلایل مختلفی از جمله قطعی اینترنت می ­تواند باعث قطع ارتباط Mobile Node با ابر شوند. در چنین شرایطی Mobile Node به صورت اتوماتیک و از طریق پیامک یا تماس اضطراری، دکتر و مسئول معماری سه لایه­ای را از این قطعی ارتباط آگاه می­ کند.
خطاهای نرم­افزار:نرم­افزار، مهمترین قسمت در لایه­ی دوم از معماری پیشنهادی است. پس نرم­افزار دستگاه موبایل باید دارای امکانات و توانایی­های ویژه­ای باشد که سازگاری و قابلیت انطباق با هر دستگاه موبایلی، از جمله­ این موارد می­باشد. حالتی را در نظر بگیرید که نرم­افزاری بسیار عالی برای لایه­ی دوم این معماری طراحی و ایجاد شده است، بگونه­ای که این نرم­افزار فقط بر روی سیستم­عامل­های اندروید نصب می­ شود. اگر چه نرم­افزار فوق برای این معماری عالی است اما لایه­ی دوم معماری را به دستگاه­هایی که سیستم­عاملشان اندروید است، محدود می­ کند. به بیانی دیگر نرم­افزار لایه­ی دوم بر روی سیستم­عامل­هایی که اندروید نیستند نصب نمی­ شود. این در حالیست که کاربر باید در انتخاب دستگاه لایه­ی دوم آزاد باشد بطوریکه با توجه به وضعیت مالی و صلیقه­اش، آزادانه دستگاه موبایل خود را بخرد. لذا نرم­افزار لایه­ی دوم باید قابلیت انطباق و سازگاری را با هر دستگاه موبایلی داشته باشد. یک راه­حل این است که برای هر سیستم­عامل یک نسخه از نرم­افزار فوق طراحی و ایجاد شود.
کدهای بداندیش^[۷۱] دیگر تهدیدات برای نرم­افزار دستگاه­های لایه­ی دو می­باشند. لایه­ی دوم به منظور ارتباط با ابر، دسترسی مستقیم به اینترنت دارد، این در حالیست که اینترنت بخاطر وجود افراد غیرمجاز و برنامه ­های مخرب، فضای ناامنی است. همچنین معمولاً افراد تحت نظارت مانند سالمندان، کاربرانی هستند که اطلاعاتی درباره کامپیوترها ندارند و خیلی سریع در دام افراد غیرمجاز و برنامه ­های مخرب اسیر می­شوند، بگونه­ای که لایه­ی دوم خراب می­ شود. به منظور تحمل این خرابی دو روش پیشنهاد می­ شود که البته هر دو روش باید با هم و در کنار هم مورد استفاده قرار بگیرند.
روش اول این است که افراد متخصص برای دستگاه لایه­ی دوم آنتی­ویروسی را در نظر بگیرند و نصب کنند که همیشه فعال باشد، و از آنجا که این لایه بخاطر ارتباطش با ابر دارای اینترنت است به صورت اتوماتیک و بدون اطلاع کاربر به مرکز پشتیبانی آنتی­ویروس وصل شود و آنرا بروز رسانی کند. روش دوم این است که برای اجرای نرم­افزار کاربر فقط آن نرم­افزار را باز کند بطوریکه ارتباط لایه دوم با کامپیوترهای پوشیدنی و ابر و همچنین پردازش داده ­ها در لایه دوم به صورت اتوماتیک و بدون دخالت کاربر صورت پذیرد. همچنین برای اجتناب از آسیب رساندن کاربر به نرم­افزار، می­توان محیط نرم­افزار را از دید کاربر مخفی کرد. بدین صورت که به محض اجرای نرم­افزار فقط آیکن کوچکی در گوشه­ی صفحه ظاهر شود و کاربر قادر به مشاهده­ محیط نرم­افزار و ایجاد تغییر در نرم­افزار، نباشد.
اگرچه می­توان از نرم­افزار لایه­ی دوم در برابر خطرات محافظت کرد، اما یک واقعیت انکارناپذیر وجود دارد و آن این است که این احتمال وجود دارد که نرم­افزار لایه­ی دو دچار نقص و خرابی شود. به بیانی دیگر، هر لحظه این امکان وجود دارد که بخاطر دلایل گوناگون، نیاز به نصب مجدد نرم­افزار باشد. در این صورت اگر کاربر تحت نظارت قادر به نصب نرم­افزار نباشد، آنگاه با مسئول معماری سه لایه­ای تماس می­گیرد، سپس فرد مسئول از راه دور و از طریق اینترنت نرم­افزار معیوب را حذف و نرم­افزار جدید را نصب می­ کند. اما اگر کاربر تحت نظارت قادر به نصب نرم­افزار باشد، می ­تواند با هماهنگی و به فرمان افراد متخصص که مسئول معماری سه لایه­ای­اند، نرم­افزار خراب شده را حذف و نرم­افزار جدید را نصب کند.
در بحث نصب مجدد نرم­افزار می­توان با روشی کاملاً ساده، نصب آنرا برای افراد با هر دانشی امکان­ پذیر کرد. بدین صورت که یک نسخه از نرم­افزار سالم در مکانی از حافظه­ گره موبایل قرار داده شود که این نسخه افزونه است. سپس بعد از خرابی نرم­افزار، باید کاربر با مسئول سه لایه تماس بگیرد و به منظور کسب اجازه از او یک نام کاربری و رمز دریافت کند. حال کاربر می ­تواند نرم­افزار افزونه را اجرا کند و نام کاربری و رمز را وارد کند تا نرم­افزار نصب شود. فرایند نصب باید بدین صورت باشد که کاربر پس از وارد کردن نام کاربری و رمز عبور هیچ دخالتی در حذف نرم­افزار خراب و نصب نرم­افزار جدید نداشته باشد به بیانی باید این دو کار به صورت اتوماتیک انجام گیرند.
اما در این فرایند نصب، ممکن است این سؤال مطرح شود که چه نیازی به کسب اجازه از مسئول معماری سه لایه­ای است؟ این سؤال را می­توان با این سؤال پاسخ داد که در حین خرابی نرم­افزار لایه­ی دو، تکلیف داده ­ها و اطلاعات ارسالی از کامپیوترهای پوشیدنی به دستگاه موبایل چه می­ شود؟ به این سؤال در بخش­های آتی جواب داده می­ شود. اما فعلاً باید خاطرنشان کرد که این معماری سه لایه­ای باید در برابر خطا و خرابی تحمل­پذیر باشد و تحت هر شرایطی در حال انجام صحیح فعالیت باشد. لذا در زمانی که نرم­افزار لایه­ی دو خراب است باید با هماهنگی مسئول معماری سه لایه­ای این خرابی را تحمل کرد.
در زمانی که نرم­افزار لایه­ی دوم خراب است، به منظور تحمل خرابی باید مانع از نابودی داده ­های ارسالی از کامپیوترهای پوشیدنی شد. به علاوه، اطلاعات تولید شده قبلی، توسط لایه­ی دو نیز، باید از بین نروند. برای چالش فوق دو راه­حل پیشنهاد می­ شود.
راه­حل اول این است که دستگاه لایه­ی دو، داده ­های دریافتی از کامپیوترهای پوشیدنی را بدون دخالت نرم­افزار لایه دو، در حافظه خودش و در درون یک پوشه تحت عنوان «داده ­های حساس» ذخیره کند. همچنین نرم­افزار لایه دو، تمامی اطلاعات تولید شده توسط خود را در حافظه­ موبایل و در پوشه ذکر شده، ذخیره کند. بطوریکه اگر بنا به هر دلیلی نرم­افزار لایه دوم خراب شد، بتوان بعد از نصب مجدد نرم­افزار، این داده ­ها و اطلاعات را مورد بررسی قرار داد. شایان ذکر است که نرم­افزار لایه دوم نرم­افزاری است که توسط مسئولین معماری سه لایه­ای ایجاد می­ شود؛ یعنی با خراب شدن این نرم­افزار، خللی در کارکرد سایر نرم­افزارها و سیستم­عامل لایه دو بوجود نمی­آید.
در راه­حل اول باید به فاصله­ی زمانی ذخیره شدن داده ­ها در پوشه «داده ­های حساس» و بررسی شدن آنها توسط نرم­افزار دوباره نصب شده، دقت شود. به طور مثال حالتی را در نظر بگیرید که نرم­افزار لایه دو خراب است. در این حین کامپیوترهای پوشیدنی داده ­های نشان دهنده ضربان قلب بیمار را برای موبایل ارسال می­ کنند، داده ­های فوق در پوشه «داده ­های حساس» ذخیره می­شوند. این داده ­ها نشان می­ دهند که ضربان قلب بیمار از دامنه­ نرمال خارج شده است و وضعیت سلامت بیمار وخیم است. در این سناریو نرم­افزار لایه دوم به فاصله­ی هفت ساعت بعد نصب مجدد می­ شود، یعنی این داده ­های ضربان قلب بعد از هفت ساعت بررسی می­شوند. این در حالی است که سلامت بیمار هفت ساعت پیش به خطر افتاده و او در آن لحظه نیاز به کمک داشته و حال ممکن است دیر شده باشد.
راه­حل دوم به منظور تحمل خرابی نرم­افزار استفاده از ابر است. این راه­حل مشکل راه­حل اول را ندارد، یعنی مواقعی که فاصله­ی بین زمان ذخیره شدن داده ­ها در حافظه­ موبایل و بررسی آنها توسط نرم­افزار دوباره نصب شده، زیاد باشد.
روش کار بدین صورت است که به محض خراب شدن نرم­افزار لایه دو، بصورت اتوماتیک محتوای پوشه «داده ­های حساس» برای ابر ارسال می­ شود. در این روش بجای انتظار کشیدن برای نصب مجدد نرم­افزار، داده ­ها و اطلاعات پوشه «داده ­های حساس» به منظور بررسی، مستقیماً به ابر فرستاده می­شوند. این ارسال اطلاعات نمی­تواند توسط Master Node فیزیکی انجام گیرد، زیرا Master Node فیزیکی به دلیل محدودیت­های سخت­افزاری و نرم­افزاری توانایی انجام وظایف Mobile Nodeرا ندارد. از این اینرو پیشنهاد می­ شود که لایه­ی دوم، خودش داده ­های دریافتی از کامپیوترهای پوشیدنی را به ابر ارسال می­ کند. در حقیقت درست است که نرم­افزار لایه­ی دو خراب است اما می­توان داده ­های ذخیره شده در حافظه دستگاه لایه دو را توسط دستگاه موبایل به ابر ارسال کرد تا خود ابر مسئولیت بررسی این داده ­ها و انجام تصمیمات بلادرنگ را بر عهده گیرد.