اپلیکیشن میدانی PWA در گاوداری؛ ثبت آفلاین اطلاعات دام در محیط واقعی فارم

مقدمه؛ نرم‌افزار گاوداری باید جایی کار کند که گاو قرار دارد

بخش بزرگی از نرم‌افزارهای مدیریتی برای محیط دفتر طراحی شده‌اند.

کاربر پشت میز می‌نشیند.

اینترنت پایدار دارد.

کیبورد و مانیتور در اختیار اوست.

محیط آرام است.

اما محل واقعی تولید داده در گاوداری، دفتر مدیریت نیست.

داخل فارم است.

کنار دام.

در سالن شیردوشی.

داخل بهاربند.

کنار زایشگاه.

در درمانگاه.

کنار باسکول.

در محل سم‌چینی.

و گاهی در محیطی با اینترنت ضعیف، رطوبت، گردوغبار و حرکت دائمی کارکنان.

در معماری فعلی سامانه رایکا نیز اپلیکیشن میدانی PWA به‌عنوان بخش مخصوص محیط فارم تعریف شده و ثبت صوتی، حالت آفلاین و اسکن پلاک با دوربین در کنار کنسول ابری مدیریتی قرار گرفته‌اند.

بنابراین سؤال اصلی این نیست که:

«آیا نرم‌افزار روی موبایل باز می‌شود؟»

سؤال درست این است:

«آیا کارگر واقعاً می‌تواند در شرایط واقعی فارم از آن استفاده کند؟»

PWA چیست؟

PWA مخفف:

Progressive Web App

است.

به زبان ساده، PWA یک برنامه مبتنی بر فناوری وب است که می‌تواند بسیاری از رفتارهای مورد انتظار از یک اپلیکیشن را ارائه کند.

از جمله:

اجرا در مرورگر
قابلیت نصب روی دستگاه در مرورگرهای پشتیبان
استفاده از Web App Manifest
Cache کردن منابع
استفاده از Service Worker
ایجاد تجربه محدود یا گسترده آفلاین
دسترسی به برخی قابلیت‌های دستگاه

MDN توضیح می‌دهد که PWAها معمولاً از Service Worker برای ایجاد تجربه Offline استفاده می‌کنند و Web App Manifest نیز اطلاعات لازم برای نحوه نمایش و نصب برنامه را در اختیار مرورگر قرار می‌دهد.

Service Worker؛ بخش مهم معماری آفلاین

یکی از فناوری‌های اساسی PWA:

Service Worker

است.

Service Worker یک لایه مستقل میان برنامه وب و شبکه ایجاد می‌کند.

درخواست برنامه می‌تواند ابتدا از Service Worker عبور کند.

در نتیجه سیستم می‌تواند تصمیم بگیرد:

اینترنت موجود است؟
      │
 ┌────┴────┐
 بله      خیر
 │          │
Server     Cache
 │          │
 └────┬─────┘
      ↓
     App

W3C، Service Worker را مکانیزمی برای پردازش رویدادمحور در پس‌زمینه وب تعریف می‌کند که از جمله می‌تواند زمینه اجرای برنامه هنگام عدم دسترسی به شبکه را فراهم کند.

Cache به چه درد فارم می‌خورد؟

فرض کنید کارگر ساعت ۷ صبح اپ رایکا را باز کرده است.

برنامه می‌تواند بخش‌هایی مانند:

رابط کاربری
آیکون‌ها
فرم‌ها
اطلاعات ضروری
تنظیمات فارم
بعضی فهرست‌های دام

را Cache کرده باشد.

ساعت ۹ اینترنت قطع می‌شود.

اگر معماری Offline درست باشد، برای باز کردن هر صفحه لازم نیست دوباره همه فایل‌ها از سرور دانلود شوند.

MDN توضیح می‌دهد که Service Worker می‌تواند Requestها را Intercept کرده و هنگام نبود شبکه پاسخ Cache‌شده را برگرداند.

اما Cache کردن صفحه با ثبت آفلاین داده فرق دارد

این تفاوت بسیار مهم است.

ممکن است برنامه بدون اینترنت باز شود، ولی نتواند اطلاعات جدید ذخیره کند.

این فقط:

Offline UI

است.

برای گاوداری کافی نیست.

اپ باید بتواند مثلاً این رخداد را نیز ذخیره کند:

Cow: IR-1001
Time: 09:16
Temperature: 39.5
Appetite: Low

حتی اگر سرور در دسترس نباشد.

بنابراین PWA واقعی برای فارم به دو لایه احتیاج دارد:

Offline Application
+
Offline Data Storage
معماری مناسب ثبت آفلاین

هنگامی که اینترنت فعال است:

کاربر
 ↓
PWA
 ↓
API
 ↓
Cloud Database

هنگامی که اینترنت قطع است:

کاربر
 ↓
PWA
 ↓
Local Database
 ↓
Pending Sync Queue

و بعد از اتصال:

Pending Queue
 ↓
Sync Engine
 ↓
API
 ↓
Cloud Database
نمونه واقعی در صنعت Dairy

این مدل فقط یک پیشنهاد نرم‌افزاری نیست.

پلتفرم AADGG-Dairy که در اکوسیستم ILRI/CGIAR توسعه یافته، برای ثبت اطلاعات دام در محیط‌هایی با اتصال ضعیف طراحی شده است.

طبق اطلاعات منتشرشده توسط FAO، اپ AADGG می‌تواند اطلاعات را در حالت Offline ثبت کند و هنگام بازگشت اتصال، آنها را به‌صورت خودکار با سرور مرکزی Sync کند.

این مدل در اکوسیستم‌های Dairy در کشورهایی از جمله:

کنیا، اتیوپی، تانزانیا، اوگاندا و نپال

استفاده و توسعه یافته است.

این نمونه برای طراحی یک سیستم گاوداری در ایران بسیار مرتبط است:

اتصال ضعیف نباید به معنی توقف ثبت اطلاعات باشد.

کاربر میدانی چه چیزهایی باید بتواند آفلاین ثبت کند؟

برای رایکا، حداقل Eventهای حیاتی بهتر است Offline-capable باشند.

مثلاً:

سلامت
تب
کاهش اشتها
لنگش
ترشح غیرعادی
کاهش نشخوار مشاهده‌شده
تولیدمثل
فحلی
تلقیح
زایش
مشاهده علائم زایش
عملیات
انتقال دام
ورود به بهاربند
خروج از بهاربند
درمان
درمان انجام‌شده
داروی مصرف‌شده
زمان اجرا
اندازه‌گیری
وزن
BCS
دما
CMT
چرا ثبت در محل بهتر از ثبت چند ساعت بعد است؟

فرض کنیم کارگر ساعت ۸ متوجه لنگش گاو می‌شود.

اما قرار است ساعت ۱۲ در دفتر اطلاعات را وارد کند.

در این فاصله باید موارد زیر را در ذهن نگه دارد:

شماره دام
بهاربند
نوع لنگش
زمان مشاهده
شدت

هرچه فاصله بین Observation و Registration بیشتر شود، احتمال از دست رفتن بخشی از Context بیشتر می‌شود.

اپ میدانی تلاش می‌کند این زنجیره را کوتاه کند:

مشاهده
 ↓
ثبت

به‌جای:

مشاهده
 ↓
حافظه
 ↓
یادداشت
 ↓
دفتر
 ↓
ورود به سیستم
ثبت آفلاین نباید Timestamp را خراب کند

یکی از مشکلات سیستم‌های ساده این است که زمان Sync را با زمان وقوع Event اشتباه می‌گیرند.

مثلاً:

کارگر ساعت:

09:20

تب را ثبت کرده است.

اینترنت ساعت:

13:40

برگشته است.

پرونده باید بگوید:

Event Time:
09:20

Sync Time:
13:40

نه اینکه بیماری ساعت ۱۳:۴۰ رخ داده باشد.

چهار زمان مختلف می‌توانند اهمیت داشته باشند

برای یک Event حرفه‌ای بهتر است این اطلاعات تفکیک شوند:

observed_at
created_at
synced_at
server_received_at

مثلاً:

Observed: 09:18
Created: 09:20
Synced: 13:40
Server received:13:40

این موضوع برای تحلیل بعدی بسیار مهم است.

هر Event باید شناسه یکتا داشته باشد

فرض کنیم اپ Offline بوده است.

وقتی اینترنت برمی‌گردد، Event ارسال می‌شود.

پاسخ سرور به دلیل اختلال شبکه به گوشی نمی‌رسد.

اپ تصور می‌کند عملیات ناموفق بوده و دوباره همان Event را ارسال می‌کند.

اگر Backend ساده باشد:

Treatment
+
Treatment

دو رکورد ایجاد می‌شود.

راه بهتر:

event_id =
550e8400-e29b-41d4...

سرور می‌بیند:

این Event قبلاً ثبت شده است.

و Duplicate نمی‌سازد.

این اصل را در طراحی API:

Idempotency

می‌نامند.

Queue آفلاین باید برای کاربر قابل مشاهده باشد

کارگر نباید مجبور باشد حدس بزند اطلاعات ثبت شده یا خیر.

مثلاً:

✓ ثبت و همگام شد

یا:

⏳ ذخیره روی دستگاه
در انتظار اینترنت

یا:

⚠ همگام‌سازی ناموفق

نمایش داده شود.

یک مثال عملی

کارگر در انتهای فارم است.

اینترنت قطع می‌شود.

او سه Event ثبت می‌کند:

09:30
IR-1001
Temperature 39.6

09:35
IR-1240
Calving started

09:42
IR-850
Lameness score 3

اپ نمایش می‌دهد:

3 Pending Records

وقتی اتصال برگردد:

Syncing...
1/3
2/3
3/3

All records synchronized
Conflict؛ مسئله سخت‌تر از Offline

فرض کنیم کارگر A آفلاین است.

در گوشی او:

IR-1240
Pen = 2

وجود دارد.

در همان زمان مدیر از دفتر ثبت می‌کند:

IR-1240
Pen 2 → Pen 6

کارگر Offline نیز Record دیگری درباره Pen همان دام ایجاد می‌کند.

پس از اتصال:

دو وضعیت متفاوت داریم.

راه‌حل Last Write Wins همیشه مناسب نیست

سیستم ساده ممکن است بگوید:

آخرین رکوردی که به Server رسید، صحیح است.

اما این می‌تواند اشتباه باشد.

زیرا رکوردی که ساعت ۹ ایجاد شده ولی ساعت ۱۳ Sync شده، نباید الزاماً روی رکورد ساعت ۱۲ غلبه کند.

بهتر است سیستم:

Event Time
Version
Type of Change
User Role

را بررسی کند.

Versioning

مثلاً:

Animal Record
Version = 18

گوشی آفلاین هنوز:

Version = 16

را دارد.

وقتی Update ارسال می‌کند، Backend متوجه می‌شود:

Client is editing stale data.

در این شرایط می‌توان:

Auto Merge

یا:

Manual Conflict Review

انجام داد.

همه Conflictها اهمیت یکسان ندارند

مثلاً دو کاربر Notes متفاوت اضافه کرده‌اند.

اینها را می‌توان Merge کرد.

اما اگر:

Pregnant = Yes

و:

Pregnant = No

هم‌زمان ثبت شوند، بهتر است سیستم Conflict را برای بررسی نشان دهد.

فرم‌های میدانی باید بسیار کوتاه باشند

داخل فارم کسی نمی‌خواهد یک فرم ۴۰ فیلدی پر کند.

مثلاً ثبت دما:

Cow ID
Temperature
Save

کافی است.

باقی اطلاعات:

User
Date
Time
Farm

می‌توانند خودکار ثبت شوند.

Progressive Disclosure

اگر کاربر بخواهد جزئیات بیشتری وارد کند:

+ توضیحات بیشتر

باز شود.

ولی فرم اولیه ساده بماند.

دکمه‌های بزرگ اهمیت دارند

اپ میدانی برای Desktop نیست.

در طراحی رابط باید در نظر گرفته شود که کاربر ممکن است:

در حال راه رفتن باشد
گوشی را با یک دست گرفته باشد
دستکش داشته باشد
نور محیط زیاد باشد

بنابراین عملیات اصلی باید با:

Large Touch Targets

قابل انجام باشد.

Quick Actions

صفحه اصلی اپ می‌تواند چند Action اصلی داشته باشد:

+ تب
+ درمان
+ زایش
+ تلقیح
+ CMT
+ BCS
+ انتقال
+ لنگش

کاربر نباید برای ثبت تب وارد پنج منو شود.

Voice-to-Form در اینجا معنی واقعی پیدا می‌کند

مقاله ثبت صوتی توضیح داد چگونه جمله:

«گاو هزار و یک، بهاربند سه، دماش سی و نه و چهار بود.»

می‌تواند به فرم تبدیل شود.

اپ میدانی جایی است که این قابلیت بیشترین ارزش را دارد.

کارگر
 ↓
Microphone
 ↓
Voice-to-Form
 ↓
Preview
 ↓
Save

در صورت نبود اینترنت، بسته به معماری واقعی محصول، Audio یا Structured Event می‌تواند موقتاً روی دستگاه نگهداری شود و بعداً Sync شود. قابلیت فعلی رایکا نیز حالت آفلاین و همگام‌سازی پس از اتصال را برای Voice-to-Form ذکر می‌کند.

یک نکته فنی مهم درباره ادعای Offline Voice

اگر Speech Recognition روی Cloud انجام شود:

No Internet
=
No immediate transcription

اما هنوز می‌توان:

Record audio
↓
Store locally
↓
Process after internet returns

داشت.

این با:

On-device Speech Recognition

متفاوت است.

بنابراین بهتر است در محصول دقیقاً مشخص شود:

در صفحه فعلی رایکا برای اپ میدانی عبارت «کارکرد کاملاً آفلاین در صورت قطعی اینترنت» آمده است.

از نظر فنی بهتر است دقیقاً مشخص شود چه Capabilityهایی Offline هستند.

مثلاً عبارت دقیق‌تر:

«عملیات حیاتی میدانی شامل مشاهده اطلاعات ضروری و ثبت رخدادها در حالت آفلاین ادامه پیدا می‌کند و داده‌ها پس از اتصال مجدد با سامانه مرکزی همگام می‌شوند.»

این ادعا هم قوی است و هم قابل اندازه‌گیری.

PWA چگونه آپدیت می‌شود؟

یکی از مزایای معماری Web این است که نسخه جدید منابع برنامه می‌تواند از Server دریافت شود.

Service Worker نسخه Cache را مدیریت می‌کند.

MDN توضیح می‌دهد که Service Worker مسئول نصب Cache، به‌روزرسانی منابع و حذف Cacheهای قدیمی نیز می‌تواند باشد.

اما Update باید کنترل‌شده باشد

فرض کنیم کارگر وسط ثبت درمان است.

نباید Update جدید ناگهان UI را Reload کند و اطلاعات ثبت‌نشده را از بین ببرد.

بهتر است:

نسخه جدید موجود است.
پس از پایان عملیات به‌روزرسانی شود.

نمایش داده شود.

App Version باید در Log ذخیره شود

مثلاً:

Event:
Treatment

App Version:
2.8.4

اگر بعداً Bug کشف شد، مشخص است کدام Recordها با نسخه مشکل‌دار ثبت شده‌اند.

اسکن پلاک با دوربین

در معماری فعلی رایکا، اسکن Barcode و پلاک گوش با دوربین موبایل نیز برای اپ میدانی ذکر شده است.

سناریوی مناسب:

Camera
↓
Barcode / QR
↓
Animal ID
↓
Cow Record

کاربر لازم نیست شماره ۱۲ رقمی پلاک را دستی وارد کند.

RFID و دوربین مکمل هم هستند

در آینده می‌توان سه روش شناسایی داشت:

Manual Search
Barcode/QR Scan
RFID

همگی باید به یک:

Internal Animal ID

برسند.

اپ میدانی نباید کل دیتابیس فارم را دانلود کند

Offline به معنی Copy کامل Database روی همه گوشی‌ها نیست.

برای یک فارم بزرگ ممکن است:

اطلاعات هزاران دام
پرونده درمان
مالی
انبار
تصاویر

وجود داشته باشد.

کارگر معمولاً فقط به بخش کوچکی نیاز دارد.

Selective Offline Sync

مثلاً کارگر Pen 3 فقط اطلاعات:

Pen 3 animals
Today's tasks
Basic health flags

را دریافت کند.

دامپزشک:

High-risk cows
Treatment history
Withdrawal

را Cache کند.

این روش:

حجم Data را کم می‌کند
Sync را سریع‌تر می‌کند
امنیت را بهتر می‌کند
امنیت داده روی گوشی

اگر اطلاعات Offline روی گوشی ذخیره شود، Device بخشی از مرز امنیتی سیستم می‌شود.

اگر گوشی گم شود، نباید هر کسی بتواند پرونده کامل فارم را مشاهده کند.

برای رایکا مناسب است:

Session Expiration
PIN یا Biometric Lock
Remote Session Revocation
محدودیت Cache
Role-Based Access

وجود داشته باشد.

نقش کاربر باید روی Backend نیز کنترل شود

صرفاً مخفی کردن دکمه کافی نیست.

اگر کارگر اجازه تغییر Diagnosis ندارد، Server نیز باید Request را رد کند.

UI Permission
+
Server Permission

هر دو لازم‌اند.

Worker چه اطلاعاتی باید ببیند؟

مثلاً:

Cow ID
Pen
Basic alerts
Tasks
Vet چه اطلاعاتی باید ببیند؟
Clinical history
Treatment
Drug
Withdrawal
CMT
CBR
Manager
All operational records
Tasks
Transfers
Reports
مالک

ممکن است اصلاً به PWA میدانی نیاز نداشته باشد و فقط Console مدیریتی را استفاده کند.

این جداسازی Roleها باعث می‌شود رابط هر شخص ساده باقی بماند.

PWA و Push Notification

Service Worker همچنین زیرساخت لازم برای برخی عملیات Background مانند Push و Sync را در وب فراهم می‌کند. MDN Service Worker را Proxy میان App، Browser و Network معرفی می‌کند و به نقش آن در Offline Experience، Push Notifications و Background Sync اشاره می‌کند.

مثلاً دامپزشک می‌تواند Alert دریافت کند:

IR-1001
تب 39.6°C
نیاز به بررسی
اما Notification باید محدود باشد

اگر دامپزشک روزانه ۲۰۰ Push دریافت کند، سیستم شکست خورده است.

اپ فقط باید:

Actionable Alerts

ارسال کند.

مثلاً:

Critical
High

Push شوند.

Watch

فقط در Dashboard باقی بماند.

Background Sync چیست؟

در برخی معماری‌های PWA می‌توان عملیات ارسال‌نشده را برای اجرای بعدی هنگام بازگشت Network ثبت کرد.

MDN این مفهوم را به‌عنوان راهی برای به تعویق انداختن Task تا زمانی که اتصال پایدار در دسترس باشد توضیح می‌دهد.

اما برای یک سیستم Enterprise بهتر است منطق Queue فقط به یک API مرورگر وابسته نباشد.

خود برنامه نیز باید Pending Queue و وضعیت Sync را مدیریت کند.

چرا؟

چون داده دامداری حساس‌تر از یک Like یا Comment است.

سیستم باید دقیقاً بداند:

چه چیزی ارسال شده؟
چه چیزی Pending است؟
چه چیزی Fail شده؟
Retry هوشمند

اگر Server در دسترس نیست:

Retry after 5 sec
↓
15 sec
↓
30 sec
↓
1 min

بهتر از ارسال مداوم Request است.

این مدل مصرف باتری و فشار Server را کاهش می‌دهد.

عکس در حالت آفلاین

کاربر ممکن است از ضایعه سم عکس بگیرد.

فایل عکس می‌تواند بزرگ باشد.

بهتر است:

Event JSON

ابتدا Sync شود.

و:

Image

در Queue جداگانه Upload شود.

چرا؟

فرض کنید اینترنت ضعیف است.

اگر عکس ۸ مگابایتی مانع Sync رکورد درمان شود، طراحی مناسب نیست.

Record حیاتی باید اولویت بالاتری داشته باشد.

Compression

تصاویر میدانی معمولاً نیازی ندارند با Resolution کامل دوربین ۵۰ مگاپیکسل Upload شوند.

می‌توان نسخه عملیاتی کوچک‌تر ساخت.

اما تصویر اصلی در موارد خاص مثل:

ضایعه
سم
سند

ممکن است برای تحلیل آینده لازم باشد.

پس سیاست فایل باید از ابتدا مشخص شود.

Offline Search

کاربر باید بتواند دام Cacheشده را حتی بدون اینترنت پیدا کند.

مثلاً:

1240

یا:

IR-1240

Search شود.

Recent Animals

در محیط فارم، کاربر معمولاً چند دام پشت سر هم را بررسی می‌کند.

بنابراین لیست:

Recently Viewed

مفید است.

Favorites / Worklist

دامپزشک صبح:

18 cows

در چک‌لیست دارد.

این ۱۸ پرونده بهتر است پیشاپیش Cache شوند.

در نتیجه حتی اگر اینترنت قطع شود:

Vet Worklist

در دسترس است.

Task-Based App بهتر از Menu-Based App است

کارگر نباید ساختار نرم‌افزار را حفظ کند.

بهتر است صفحه اصلی بگوید:

کارهای امروز

12 بررسی سلامت
8 انتقال
6 CMT
4 واکسیناسیون

این UX عملیاتی‌تر است.

مطالعه واقعی AADGG چه نکته‌ای برای رایکا دارد؟

پلتفرم AADGG نشان می‌دهد که ثبت داده فردی دام در محیط‌هایی با Connectivity محدود می‌تواند با Mobile App، Offline Capture و Central Synchronization عملی شود.

اما رایکا محیط متفاوتی دارد:

AADGG عمدتاً برای سیستم‌های Smallholder و Data Recording توسعه یافته است.

رایکا برای یک Farm صنعتی می‌تواند Workflowهای پیچیده‌تری مانند:

درمان
BI
Voice
Digital Twin
TMR
CBR

را اضافه کند.

پس AADGG نمونه معماری مرجع است، نه معادل محصول رایکا.

کنیا

فناوری AADGG در کنیا برای ثبت و مدیریت اطلاعات دام Dairy مورد استفاده قرار گرفته است.

اتیوپی

پلتفرم AADGG ابتدا در کشورهایی از جمله اتیوپی توسعه و آزمایش شده و اطلاعات دام را برای اهداف تولیدی و ژنتیکی جمع‌آوری می‌کند.

تانزانیا

تانزانیا نیز از کشورهای اصلی توسعه و Scale این اکوسیستم ثبت داده Dairy بوده است.

اوگاندا و نپال

پلتفرم بعداً به این کشورها نیز گسترش یافته و استفاده از Mobile Data Capture در آنها گزارش شده است.

چرا این کشورها برای ایران مهم‌اند؟

نه به دلیل شباهت صنعت دامپروری.

بلکه از یک جنبه فنی:

طراحی نرم‌افزار بدون فرض اینترنت دائمی.

این اصل برای بسیاری از فارم‌های ایران نیز منطقی است.

PWA در برابر Native App

هیچ‌کدام مطلقاً بهتر نیستند.

PWA مزایایی دارد:

یک Codebase
Web deployment
Installability
Offline capabilities

Native نیز در بعضی موارد مزیت دارد:

Hardware integration
Deep background services
Vendor SDKs
Special Bluetooth/RFID

بهترین تصمیم بر اساس نیاز واقعی تجهیزات فارم گرفته می‌شود.

چه زمانی PWA برای رایکا مناسب است؟

اگر تمرکز اصلی روی:

فرم
پرونده
Voice
Camera
Task
گزارش
Offline Queue

باشد، PWA می‌تواند گزینه بسیار جذابی باشد.

چه زمانی Native Layer ارزش پیدا می‌کند؟

اگر نیاز جدی به:

RFID Reader اختصاصی
Bluetooth Sensor
Background continuous collection
Vendor hardware SDK

وجود داشته باشد، یک Native یا Hybrid Layer ممکن است لازم شود.

معماری Hybrid

مثلاً:

Raika PWA
      │
      ├── Forms
      ├── Records
      ├── Tasks
      └── Voice

Native Bridge
      │
      ├── RFID
      ├── Bluetooth
      └── Hardware

هر دو به یک Backend متصل شوند.

یک Backend؛ اصل مهم

PWA و Web Console نباید دو سیستم مستقل باشند.

باید:

PWA ─────┐
         ├── Raika API → Database
Web ─────┘

باشند.

در نتیجه هر دو یک Business Logic دارند.

مثلاً Days Open

نباید PWA بگوید:

118

و Console:

121

چون هر دو باید عدد را از یک Engine بگیرند.

معماری پیشنهادی کامل
                RAİKA FIELD PWA
                       │
              ┌────────┴─────────┐
              │                  │
         Online Mode        Offline Mode
              │                  │
              │             Local Database
              │                  │
              │             Pending Queue
              │                  │
              └────────┬─────────┘
                       │
                    Sync API
                       │
                       ▼
                RAİKA CLOUD
                       │
       ┌───────────────┼──────────────┐
       ▼               ▼              ▼
   Database          Files         AI Engines
       │
       ├── Electronic Record
       ├── Digital Twin
       ├── CBR
       ├── Monitoring
       ├── BI
       └── Copilot
رابطه با Cloud Sync

مقاله قبلی درباره Cloud Sync بود.

PWA بخش Field این معماری است.

PWA
=
محل تولید داده

Cloud Sync
=
انتقال و هماهنگی داده

این دو مکمل یکدیگرند.

رابطه با پرونده الکترونیک

کاربر از داخل بهاربند Event ثبت می‌کند.

PWA
↓
Event
↓
Cloud
↓
9-tab Record
رابطه با Digital Twin

مثلاً دما ثبت می‌شود:

39.5°C

پس از Sync:

Digital Twin Update

می‌شود.

رابطه با CBR

دامپزشک می‌تواند پرونده بیمار را در همان گوشی باز کند و موارد مشابه گذشته را مشاهده کند.

رابطه با AI Farm Copilot

کاربر می‌تواند داخل فارم بپرسد:

«امروز کدوم دام‌های این بهاربند نیاز به بررسی دارند؟»

و Copilot Worklist مربوط را نمایش دهد؛ این بخش طبیعتاً زمانی به داده کامل Cloud دسترسی خواهد داشت که اتصال لازم فراهم باشد.

رابطه با BI

PWA خودش Executive Dashboard نیست.

اما تمام Dataهای ثبت‌شده از میدان در نهایت BI را تغذیه می‌کنند.

Field Data
↓
Cloud
↓
BI
اپ میدانی در واقع مهم‌ترین نقطه Data Quality است

مدیر می‌تواند بهترین Dashboard جهان را داشته باشد.

اما اگر کارگر:

بیماری را ثبت نکند
پلاک اشتباه بزند
زمان اشتباه ثبت کند

Dashboard نیز اشتباه خواهد بود.

پس PWA فقط یک Interface نیست.

دروازه ورود داده واقعی فارم است.

KPIهای خود اپ میدانی

موفقیت این ماژول را باید اندازه‌گیری کرد.

مثلاً:

• Event Capture Rate
• چند درصد رخدادهای مشاهده‌شده ثبت شدند؟
• Median Entry Time
• ثبت یک Event چند ثانیه طول می‌کشد؟
• Offline Success Rate
• چه درصدی از Eventهای Offline بعداً صحیح Sync شدند؟
• Duplicate Rate
• چند Event Duplicate ایجاد شد؟
• Correction Rate
• چند درصد فرم‌ها نیازمند اصلاح بودند؟
• Sync Failure Rate
• چند Record Sync نشد؟
• KPI مهم دیگر: Time to Record

قبل از PWA:

Observation → Database
Median = 75 min

بعد:

Median = 2 min

اگر رایکا بتواند چنین داده‌ای از فارم واقعی جمع کند، یک ادعای تجاری بسیار قوی و قابل اثبات خواهد داشت.

ثبت سه‌برابری رخدادها نیز باید همین‌طور اثبات شود

در صفحه فعلی رایکا برای Voice-to-Form «ثبت ۳ برابری رخدادهای میدانی» ذکر شده است.

برای اثبات علمی باید:

Before PWA/Voice
vs
After PWA/Voice

مقایسه شود.

مثلاً:

قبل:
860 Event/month

بعد:
2,300 Event/month

و شرایط دو دوره کنترل شوند.

بهترین مطالعه میدانی برای این ماژول

می‌توان دو گروه کاربر داشت.

روش سنتی
Paper / Office Entry
روش PWA
On-site Mobile Entry

سپس مقایسه:

زمان ثبت
تعداد Event
خطای Animal ID
Missing Fields
رضایت عملیاتی
درصد Sync موفق

انجام شود.

PWA نباید کاربر را مجبور به Login دائمی کند

اگر هر بار که اینترنت لحظه‌ای قطع شد Session از بین برود، برنامه در فارم قابل استفاده نیست.

Session Management باید با Offline Operation سازگار باشد.

اما امنیت نیز باید حفظ شود.

تعادل:

Usability
↔
Security

ضروری است.

خروج از حساب از راه دور

اگر گوشی کارگر گم شد:

Manager باید بتواند Session آن دستگاه را غیرفعال کند.

Device 18
Status:
Revoked
Device Registration

هر دستگاه بهتر است شناسه مشخص داشته باشد:

Device ID
User
Last Sync
App Version

تا مشکلات قابل Trace باشند.

Data Minimization

گوشی کارگر نباید اطلاعات مالی شرکت را Cache کند.

اصل:

Only data needed for the role

امن‌تر است.

Audit

هر Event باید مشخص کند:

Registered by:
User 184

Device:
FIELD-07

Time:
09:16

Mode:
Offline

اگر بعداً سؤال ایجاد شد، منشأ Data مشخص است.

آینده؛ PWA به مرکز عملیات میدانی تبدیل می‌شود

نسل اول:

Digital Forms

نسل دوم:

Offline Forms

نسل سوم:

Voice + Camera + AI

نسل چهارم:

Context-Aware Field Assistant

یعنی برنامه خودش می‌داند:

کاربر کدام Pen است
امروز چه Taskهایی دارد
چه دام‌هایی نیازمند بررسی‌اند
کدام Eventها Pending هستند
یک سناریوی آینده

دامپزشک وارد Pen 3 می‌شود.

اپ نمایش می‌دهد:

Pen 3

12 cows on today's vet list
3 High Priority

اولین گاو:

IR-1001

پرونده Cache شده است.

دامپزشک معاینه می‌کند.

Treatment را ثبت می‌کند.

اینترنت موجود نیست.

Saved Offline

۳۰ دقیقه بعد اتصال برمی‌گردد.

Treatment Sync می‌شود.

دوره پرهیز فعال می‌شود.

دارو از Inventory کم می‌شود.

پیگیری فردا ساخته می‌شود.

BI به‌روز می‌شود.

این همان مفهوم Digital Field Workflow است.

نتیجه‌گیری

یک نرم‌افزار گاوداری زمانی واقعاً میدانی است که بدون تغییر رفتار طبیعی کارکنان بتواند در همان جایی که اتفاق رخ می‌دهد Data دریافت کند.

PWA می‌تواند رابط میان:

انسان داخل فارم

و:

سامانه ابری مدیریت

باشد.

اما ارزش واقعی آن فقط در نصب شدن روی Home Screen نیست.

یک PWA حرفه‌ای برای گاوداری باید بتواند:

در اتصال ضعیف کار کند
فرم‌های ضروری را آفلاین اجرا کند
رخدادها را محلی ذخیره کند
زمان واقعی Event را حفظ کند
Pending Queue داشته باشد
پس از اتصال Sync کند
Duplicate را تشخیص دهد
Conflict را مدیریت کند
وضعیت Sync را به کاربر نشان دهد
سطح دسترسی کاربران را رعایت کند
با Voice، Camera و پرونده دام یکپارچه باشد

نمونه‌هایی مانند AADGG نشان می‌دهند Offline Mobile Livestock Recording در کشورهای مختلف به‌طور عملی پیاده‌سازی شده است.

استانداردهای Web نیز زیرساخت‌هایی مانند Service Worker، Cache و پردازش رویدادمحور را برای ایجاد چنین تجربه‌هایی فراهم می‌کنند.

در نهایت، هدف اپ میدانی این نیست که کارگر «بیشتر با نرم‌افزار کار کند».

هدف دقیقاً برعکس است:

زمان تعامل با نرم‌افزار کم شود، ولی مقدار و کیفیت اطلاعات واقعی فارم افزایش پیدا کند.

وقتی ثبت اطلاعات از دفتر به محل وقوع Event منتقل شود، فاصله بین:

واقعیت فارم

و:

آنچه سیستم درباره فارم می‌داند

به حداقل می‌رسد.

و این همان پایه‌ای است که تمام ماژول‌های بعدی هوش مصنوعی، Digital Twin، CBR، BI و تصمیم‌یار رایکا روی آن ساخته می‌شوند.