מצגת זו מניחה ידע מועט מאוד

אינכם זקוקים לרקע באבטחה פיזית, מנעולים או תוכנת ענן.

המצגת הזו מיועדת ל:

• דיירים ומשתמשים יומיומיים שיפתחו דלתות באמצעות טלפון
• מנהלי נכסים שינהלו אתר
• אדריכלי פתרונות שיצטרכו להתאים את OpenApp לצד חומרה ותוכנות אחרות
• משקיעים ובעלי עניין שצריכים להבין מהו המוצר

אם מילה היא ז'רגון, אנו נגדיר אותה לפני השימוש בה.

מה נכסה

1. מהי דלת באמת (החלטה, לא רק מנעול)
2. מדוע מבנים עדיין מתמודדים עם בעיות גישה
3. כיצד פתרונות אחרים פועלים בדרך כלל
4. כיצד OpenApp פועלת, חלק אחר חלק
5. מה הופך את המודל הזה ליוצא דופן
6. מקרי שימוש בבתים, דיור, עבודה, אירוח, קמפוס ולוקרים

הרצאות עתידיות יכולות להעמיק בכל אחד מהנושאים הללו. מצגת זו היא המפה.

מה מצגת זו אינה

• לא סיור מוצר מסחרי
• לא אריזה מסחרית או חומר שיווקי
• לא השוואת ספקים או ניתוח נתח שוק
• לא מדריך התקנה לחיווט, קוד אש או תכנון חומרה מאושר

נושאים אלה נמצאים במקומות אחרים. כאן אנו מתמקדים בבקרת גישה: מי רשאי להיכנס,
כיצד, מתי, וכיצד ניתן לראות מה קרה.

כיצד להשתמש בשקפים

• הבא: חץ ימינה, רווח, או Page Down
• הקודם: חץ שמאלה או Page Up
• מסך מלא: F
• רשימת מקשים: ?

כל חלק עיקרי מתחיל במפריד צבעוני. עברו עליהם במהירות אם אתם כבר מכירים את היסודות;
האטו במקומות שבהם המודל חדש.

אתם כבר מבצעים בקרת גישה

חשבו על הבוקר הזה.

• מפתח לביתכם
• תג או פוב בעבודה
• קוד בלוח מקשים של שער
• איש צוות שמכניס מישהו
• כרטיס מלון שמפסיק לעבוד בעת יציאה

זוהי בקרת גישה: החלטה מי רשאי לעבור מחסום פיזי, וביצוע ההחלטה הזו במחסום.

אבטחה פיזית, בשפה פשוטה

אבטחה פיזית היא האופן שבו מקום מגן על עצמו בעולם האמיתי: קירות,
דלתות, שערים, מצלמות, אנשים בדלפק.

בקרת גישה היא החלק שעונה על השאלה:

האם אדם זה רשאי לעבור דרך פתח זה, ברגע זה?

OpenApp עוסקת בשאלה זו – ובהפעלתה היטב על פני פתחים רבים,
אנשים רבים וסוגי חומרה רבים.

חמש שאלות שכל פתח חייב לענות עליהן

1. מי שואל? דייר, אורח, שליח, זר, מערכת.
2. היכן? לובי, חניה, דלת דירה, שער שירות, תא לוקר.
3. מתי? יום שלישי 14:00 אינו זהה ליום שבת 03:00.
4. כיצד הם מוכיחים זאת? מפתח, פוב, טלפון, קישור הזמנה, שיחה לדייר.
5. מה מתועד? אם משהו משתבש, האם ניתן לשחזר זאת?

מערכת רצינית אינה "אפליקציה שפותחת ממסר". זוהי דרך לענות על
חמש השאלות הללו באופן עקבי.

חמשת אבני הבניין

תפקידה של OpenApp הוא לשמור על חמשת אלה במודל קוהרנטי אחד – גם כאשר מותג המנעול,
האינטרקום וזרימת האורחים מגיעים מעולמות שונים.

מדוע זה קשה יותר מחלוקת מפתחות

מפתחות פשוטים עד שהם לא:

• מישהו עובר דירה ואתם אף פעם לא מקבלים את המפתח בחזרה
• קבלן צריך שעתיים, לא לנצח
• נהג משלוחים נמצא בשער, לא בדלת הדירה
• לבניין יש שנים עשר פתחים, לא אחד
• שני בניינים חולקים שער חניה
• עליכם להראות מי פתח מה לאחר אירוע

גישה פיזית היא בעיה של אנשים וזמן הלובשת תחפושת חומרה.

זהות דיגיטלית אינה זהה לעמידה ליד דלת

התחברות לאתר מוכיחה "חשבון זה רשאי לראות דף זה".

פתיחת דלת דורשת גם:

• הפתח הנכון (לא כל דלת באתר)
• הרגע הנכון (לא לאחר יציאה, לא במהלך עוצר)
• מפעיל נגיש (המנעול או מנוע השער אכן מופעלים)
• לעיתים קרובות אדם בלולאה (דייר שעונה למבקר)

OpenApp יושבת בצומת זה: זהות תוכנה בתוספת פעולה פיזית.

שתי דרכים להפעלת תוכנה

תוכנה מותקנת: אתם (או האינטגרטור שלכם) מתקינים תוכנה על מחשב בחדר החשמל. אתם דואגים לעדכונים. אם המחשב הזה קורס, זרימת העבודה קורסת איתו.

תוכנה כשירות (SaaS): אתם משתמשים במוצר דרך האינטרנט. הספק מפעיל את השרתים, את השדרוגים ואת הגיבויים. אתם מתחברים ועובדים.

רוב הכלים העסקיים המודרניים – דוא"ל, הנהלת חשבונות, הזמנות – הם SaaS. בקרת גישה הייתה איטית יותר לאמץ זאת, מכיוון שדלתות הן פיזיות ובעבר היו מקומיות.

מדוע בניין עשוי לרצות מישור בקרה בענן

מישור בקרה הוא המוח: משתמשים, הרשאות, הזמנות, ספריות, ביקורת. החומרה היא השריר: מנעולים חשמליים, מנועי שערים, ממסרים.

בקרת ענן עוזרת כאשר יש לכם:

• יותר מאתר אחד
• צוות שאינו עומד ליד מחשב במרתף
• אורחים שלא צריכים להתקין אפליקציית ספק
• תוכנות אחרות (הזמנות, נכסים, קמפוס) שחייבות לתקשר עם דלתות

המנעול יכול להישאר על הקיר. המדיניות לא חייבת לחיות רק שם.

אבטחה פיזית כשירות

OpenApp היא אבטחה פיזית כשירות (PSaaS).

משמעות הדבר:

• בקרת גישה מסופקת כפלטפורמה מתארחת
• אתם מחברים את החומרה שתבחרו
• אנשים משתמשים בחוויה קוהרנטית אחת (טלפון, דפדפן, לוח מחוונים)
• מערכות אחרות יכולות להפעיל את אותם כללים באמצעות ממשקי API

PSaaS אינה "חברת מצלמות" ואינה "מפעל מנעולים". זוהי השכבה שמתזמרת כניסה.

אתר טיפוסי הוא ערימה של מוצרים חלקיים

היכנסו לבניין מעורב ותמצאו לעיתים קרובות:

• פאנל לובי מדור קודם עם ספרייה מודפסת
• שער חניה עם אפליקציה משלו
• פובים שתכנתו על מחשב שולחני בארון
• ממסר Wi‑Fi שמישהו התקין לדלת צדדית
• גיליון אלקטרוני של קודי אורחים
• אין תמונה אחת של מי יכול לעשות מה

כל חלק עשוי לעבוד. המערכת לא.

פיצול הוא ברירת המחדל

ספקים מייעלים עבור המכשיר שלהם:

• האפליקציה שלהם
• רשימת המשתמשים שלהם
• תפיסתם לגבי "אורח"
• פורמט התיעוד שלהם, אם יש כזה

אנשים לא חיים כך. אדם אחד הוא דייר כאן, חבר שם, ואורח במקום אחר – השבוע.

אם כל דלת היא מוצר אחר, תהליכי עזיבה ואורחים הופכים לפולקלור.

נעילת חומרה מול שימוש חוזר בחומרה

שני מצבי כשל, בכיוונים מנוגדים:

1. החלפה מוחלטת: מוצר תוכנה חדש שתומך רק בקוראים שלו
   ובפאנלים שלו. השער שעבד אתמול מוכרז כמיושן.
2. תקועים עם שאריות: אתם שומרים חומרה ישנה, אך התוכנה היחידה היא
   אפליקציית דסקטופ מ-2008 ואינטרקום קווי.

מישור בקרה מודרני צריך לכבד חומרה עובדת ועדיין לספק לכם
חווית מפעיל עדכנית.

אורחים ומשלוחים הם אזרחים סוג א', לא מחשבה שנייה

רוב המערכות מתוכננות סביב עובדים או דיירים.

באתרים אמיתיים יש גם:

• מנקים בחלון זמן של יום שלישי
• משלוחי רהיטים
• שהיות קצרות
• מבקרי אירועים
• הורים שאוספים ילדים
• שליחים שצריכים לפתוח תא אחד, לא את הבניין

אם "הוספת אורח" פירושה חיתוך פוב, תהיו איטיים או לא בטוחים.

אינטרקום הפך למוצר נפרד

במשך עשרות שנים, "לדבר עם הדירה" פירושו פאנל על הקיר, מחובר
לשפופרות.

ואז טלפונים השתפרו. מבקרים כבר נושאים מחשב. דיירים כבר
נושאים מחשב.

אך אתרים רבים עדיין רוכשים:

• מוצר אחד לפתיחה
• מוצר אחר לקריאה ליחידה
• דבק באמצע שאף אחד לא מחזיק בו

כניסה היא רגע אנושי אחד. יש לאפשר לתוכנה להתייחס אליו כאחד.

ריבוי אתרים, חומרה מעורבת, ארגונים מעורבים

מפעיל קטן עשוי להחזיק ב:

• בית עם פותחן Wi‑Fi זול
• בניין בן 40 יחידות עם שער סלולרי
• קומת עבודה משותפת עם דלתות פנימיות רבות
• אגף מלון שעדיין משתמש במנעול חדר ייעודי

האנשים עוברים בין אתרים אלה. החומרה אינה תואמת. מודל הניהול
בדרך כלל מניח ספק אחד ודייר אחד.

חוסר התאמה זה הוא המשימה.

תיעוד חלש, ביטול איטי

כאשר משהו קורה ב-02:14, אתם רוצים לדעת:

• מי הציג מה
• איזה פתח
• האם זה אושר או נדחה
• האם זה היה דייר, הזמנה או שיחת מבקר

יומני רישום מדור קודם רבים הם מקומיים, חלקיים או בלתי ניתנים לייצוא. אפליקציות צרכניות רבות מציגות ציר זמן חמוד ולא משהו שרואה חשבון יכול להשתמש בו.

וכאשר מישהו צריך לאבד גישה היום, איסוף מפתחות מתכת אינו תהליך עבודה. ביטול חייב להיות פעולת תוכנה.

לשאר הבניין כבר יש תוכנה

למלונות יש מערכת לניהול נכסים.
לדירות נופש יש מערכת הזמנות / ניהול דירות נופש.
לקמפוסים יש מערכת מידע לסטודנטים.
למשרדים יש לעיתים קרובות מערכת לניהול מקום עבודה / מתקנים.

מערכות אלו כבר יודעות מי צריך להיות כאן, ועד מתי.

אם בקרת הגישה אינה יכולה להיות מונעת על ידי אמת זו, הצוות יקליד אותה מחדש, ו
הדלת תהיה שגויה.

מפתחות מכניים

כיצד זה עובד: מפתח פיזי תואם לצילינדר. עותקים הם ממתכת.

יתרונות: אין רשת, אין סוללה באישור הגישה, כולם מבינים זאת.

מגבלות: עותקים שאינכם יכולים לראות; מפתחות אבודים; אורחים בעייתיים; אין תיעוד שימושי;
צילינדר אחד לכל שינוי דעה.

מפתחות נשארים פתרון גיבוי מצוין. הם מערכת ראשית גרועה
ברגע שאוכלוסיית המשתמשים מתחלפת.

פובים, כרטיסים ובקר מקומי

כיצד זה עובד: כל אדם מקבל אסימון. קופסה בבניין מחליטה.
התוכנה לרוב מותקנת על מחשב מקומי.

יתרונות: מוכר לספקי אבטחה; יכול להיות חזק ברשת מקומית.

מגבלות: המחשב הזה הוא נקודת כשל יחידה; ניהול מרחוק מסורבל;
גישת אורחים היא משימת תכנות מייגעת; ריבוי אתרים פירושו איים רבים.

זהו עמוד השדרה של כמות עצומה של מלאי דיור ומשרדים קיים.

אינטרקום לובי מדור קודם

כיצד זה עובד: פאנל קיר מציג רשימת יחידות. מבקר מקיש מספר. טלפון או
שפופרת מצלצלים בדירה. הדייר פותח את הדלת.

יתרונות: מבקרים אינם זקוקים לחשבון; זה יכול לעבוד כאשר הנייד של דייר אינו עובד; מתקינים מכירים זאת.

מגבלות: ספריות מתיישנות; אין קישור אורח למנקה; אין API למערכת הזמנות; ספק נוסף מלבד ספק המנעולים.

תפיסת OpenApp: שמרו אותו כגיבוי כאשר טלפונים או רשתות נכשלים. אל
תתיימרו שדרך מבוססת טלפון בלבד זהה לפאנל קווי.

מערכות בקרת גישה ארגוניות

כיצד זה עובד: קוראים ובקרים סטנדרטיים, תוכנה מרכזית,
לוחות זמנים וביקורת המיועדים למשרדים תאגידיים.

יתרונות: בשלים עבור "IT מחזיק בכל דלת"; חזקים בקמפוסים אחידים של
אותה משפחת חומרה.

מגבלות: לעיתים קרובות אינם מתאימים להאצלת סמכויות לכל דירה, הזמנות לשהייה קצרה,
ופותחני IoT מעורבים. בחירת החומרה היא לעיתים קרובות קטלוג הספק, לא שלכם.

השתמשו בתבנית זו כאשר האתר הוא משרד כזה. אל תכפו עליה דיור.

חבילות נכסים הכל-באחד

כיצד זה עובד: חברה אחת מוכרת את המנעול, האפליקציה וכלי המפעיל
כחבילה.

יתרונות: כתובת אחת לכל הבעיות; אפליקציית דיירים מלוטשת אם אתם מקבלים את
החבילה.

מגבלות: התקנה בדיעבד כואבת; שערים קיימים מעורבים הם סוג ב'; אתם
יורשים את מפת הדרכים שלהם לאינטרקום, אורחים וממשקי API.

מתאים לבנייה חדשה שרוצה את המערכת האקולוגית הזו. מסורבל עבור "כבר יש לנו
שער עובד".

תוכנת ביניים למנעולים

כיצד זה עובד: API מתארח שמדבר עם מותגי מנעולים חכמים רבים. אתם
בונים את השאר: לוח המחוונים שלכם, ההזמנות שלכם, האינטרקום שלכם, חווית המשתמש של הביקורת שלכם.

יתרונות: מהיר אם עולמכם הוא מנעולים נתמכים ואתם צוות תוכנה.

מגבלות: שערים, ממסרים, פותחני Field-Bus וקריאה ללובי הם הבעיה שלכם.
תוכנת ביניים אינה מוצר גישה מלא.

אם הייתם צריכים רק אסימוני מנעול, זה יכול להספיק. אם הייתם צריכים בניין,
זהו רכיב.

אוטומציה עשה זאת בעצמך

כיצד זה עובד: רכזת אוטומציה ביתית, כמה ממסרים, סקריפטים, אולי מיני-אפליקציה מותאמת אישית.

יתרונות: טווח חומרה עצום; נהדר לבית או למעבדה בעלי ביטחון טכני.

מגבלות: הרגע הפכתם לספק עבור זהות, הזמנות, ביקורת,
האצלה וזמן פעולה. זהו מוצר, לא פרויקט סוף שבוע.

OpenApp יכולה להשתמש ברכזת כגשר. היא לא צריכה לאלץ אתכם להפוך למישור הבקרה.

הערימה המפוצלת

נפוץ במלונות ובדיור גדול יותר:

ערימות מפוצלות הן רציונליות כאשר כל מומחה הוא כבר עלות שקועה. הן
יקרות כפילוסופיה.

מה משותף לכל אלה

כל אחד מהם מייעל פלח אחד:

• הצילינדר
• משפחת הקוראים
• פאנל הלובי
• ממשק ה-API של המנעול
• הרכזת

כמעט אף אחד לא מתחיל מהדבר שאנשים באמת עושים:

להגיע למקום, להוכיח שאתם שייכים (או לבקש ממישהו ששייך), לעבור
מחסום, להשאיר תיעוד.

OpenApp מתחילה שם, ואז מחברת חומרה כמודולים.

OpenApp בפסקה אחת

OpenApp היא מישור בקרה בענן לגישה פיזית.

היא מתחברת לפותחנים שכבר יש לכם או שתקנו, ממדלת אתר
(ספרייה, דלתות, אנשים, מדיניות), ומאפשרת לדיירים, אורחים ומבקרים
לפעול דרך פורטלים – בדרך כלל שלט בדלת עם קוד QR, הקשת NFC, או
קישור קצר.

אותה פלטפורמה היא גם API, כך שתוכנות הזמנות וניהול נכסים יכולות
להניע הזמנות ופתיחות ללא מוצר גישה שני.

מישור בקרה מול חומרה

תוכנה אינה מחליפה את המנגנון. היא מחליטה מתי מותר למנגנון
לפעול, ומי ביקש זאת.

אינכם חייבים להחליף הכל

בכל פעם שזה מעשי, עשו שימוש חוזר במה שכבר נפתח.

דרכים שאנשים משתמשים בהן:

• תקשורת עם ענן ספק או רכזת שכבר אתם מפעילים
• גישור ציוד ישן יותר דרך מערכת אוטומציה מקומית
• חיבור בקר שהיה לא מקוון לרשת באופן שמתאים לבטיחות

אם אינטגרציה קטלוגית עדיין לא קיימת, זו שיחה – לא
אולטימטום לעקור שער עובד.

ארגונים, אתרים ובניינים

ארגון הוא גבול המפעיל: בעל בית, חברת מלונות, מחלקת קמפוס,
משק בית שרוצה מרחב עבודה משלו.

אתר הוא מקום שאתם מנהלים ב-Access: בית, קהילה מגודרת,
מגדל, אשכול קמפוס.

בניין, בשפת OpenApp, הוא במיוחד צורת הספרייה + אינטרקום
וירטואלי: קומות, דירות, מי מקבל שיחת מבקר.

ארגון אחד יכול לנהל אתרים רבים. אתרים יכולים לחלוק דפוסים מבלי לחלוק
גישה מקרית.

אדם אחד, הרשאות רבות

OpenApp אינה מתייחסת לאדם כרכוש של ארגון לקוח יחיד.

אתם משתמש אחד. הגישה היא מצטברת:

• דייר בבניין אחד
• חבר שולחן בארגון אחר
• אורח עם הזמנה מוגבלת בזמן מצד שלישי

הרשאות מגיעות מהקצאות ומענקים, לא מתג שאומר
"זהו ביתכם היחיד במסד הנתונים".

זה תואם את החיים האמיתיים. רוב המערכות נלחמות בזה.

אינטגרציות, מכשירים וישויות

שלוש שכבות יושבות מתחת לכל פתח:

1. אינטגרציה – חיבור לספק (ענן, רכזת, פרוטוקול, או
   Virtual Access של OpenApp).
2. מכשיר – קופסה פיזית או וירטואלית אחת בחיבור זה.
3. ישות – דבר הניתן לשליטה במכשיר: ערוץ ממסר, אור,
   תא.

פתיחת דלת אינה "API קסום לדלת". זוהי פעולה על ישות, כגון
פתיחה, כאשר OpenApp מחליטה אם פעולה זו מותרת.

Virtual Access הוא מודל הבניין

Virtual Access היא הדרך המקורית של OpenApp למדל אתר עבור אנשים:

• ספרייה של דירות / יחידות
• דלתות ושערים כמכשירי פורטל
• אנשים המקושרים ליחידות
• פורטלים ציבוריים (השלטים)
• הזמנות

היא אינה מחליפה את המנעול. היא מתזמרת פעולות מנעול דרך
הפותחנים שקישרתם.

חשבו עליה כעל מערכת ההפעלה של הבניין, לא כעל מותג חומרה נוסף.

הספרייה (יחידות שאנשים יכולים למצוא)

כל יחידה היא דירה במודל הנתונים – גם אם במציאות היא משרד,
חדר מלון או סטודיו.

הספרייה יכולה להכיל:

• שמות תצוגה ביותר משפה אחת
• תוויות קומה
• תמונות
• אילו פעולות מבקרים מותרות (שיחה, הודעה וכן הלאה)

מבקרים אנונימיים רואים ספרייה, לא מאגר של נתוני קשר פרטיים.
המדיניות קובעת כמה גלוי ומה הם רשאים לעשות.

דלתות, שערים ופותחנים

דלת (או שער, מחסום, חניה) היא מכשיר פורטל ב-Virtual Access. היא
יודעת:

• אילו פותחנים לנסות (וגיבוי אם נתיב אחד נכשל)
• אורות אופציונליים עם טיימר
• סגירה אוטומטית כך שמנגנון הנעילה לא יישאר מופעל
• מצלמות אופציונליות לצפייה חיה במהלך שיחה או בדיקת מפעיל

התנועה הפיזית היא תמיד: OpenApp מבקשת מפותחן משולב לפתוח.
מותג הפותחן הזה הוא תוסף, לא המוצר.

פורטל הוא השלט שעל הדלת

בשטח, פורטל הוא מה שאתם מתקינים: לוחית, מדבקה, עמוד בנתיב.

מאחוריו נמצאת זהות ציבורית יציבה – כתובת URL בצורת /p/{id} – המוצגת כ:

• קוד QR
• הקשת NFC (טלפון או שעון)
• קישור קצר מודפס
• קישור בהודעה לאורח שעדיין לא נמצא באתר

מפעילים חושבים "שלט הלובי". תוכנה חושבת "נקודת הכניסה העמידה".
אם אתם מחליפים את המנעול, אתם מכוונים מחדש את הפורטל. אינכם מדפיסים מחדש את
הבניין.

אותו פורטל, חוויה שונה

כתובת ה-URL ציבורית. מה שהיא עושה תלוי במי אתם:

שלט אחד. שלושה מצבים כנים. אין "אפליקציית אורחים" נפרדת כדי להכשיר את השליח.

הזמנות: גישה ללא חשבון

הזמנה היא הרשאה מוגבלת בזמן: פורטל זה, חלון זמן זה, מספר שימושים זה,
מותג אופציונלי.

האורח פותח קישור. OpenApp יכולה לשמור סשן מינימלי במכשיר זה
כך שהסריקה הבאה של אותו שלט תהיה פתיחה בלחיצה אחת – עד שההזמנה
תסתיים.

דיירים ומנהלים אינם "אורחים". עוצרים ומגבלות הזמנה מכוונים לגישה
מבוססת הזמנות, לא לאנשים שגרים שם.

אינטרקום וירטואלי

מבקר בשלט יכול לבחור יחידה ו:

• לבצע שיחת קול או וידאו
• לשלוח הודעה, כאשר אתם מאפשרים זאת
• לאחר שדייר מקבל, לפתוח אם המדיניות מאפשרת זאת

הניתוב משתמש באנשים המקושרים לדירה זו – במיוחד אלה המסומנים
לקבל שיחות.

אפליקציית הדייר משתמשת בחוויית השיחה הנכנסת הרגילה של הטלפון. המבקר
יכול להישאר בדפדפן נייד. פאנל הלובי הוא אופציונלי, לא מרכז
היקום.

תפקידים מעניקים. מדיניות רק מגבילה.

תפקידים עונים: מי רשאי לפעול?
(מנהל אתר זה, דייר דירה זו, טכנאי, ...)

מדיניות עונה: תחת אילו מגבלות?
הן לעולם אינן מעניקות כוח נוסף. הוספת מדיניות יכולה רק לצמצם את מה שכבר
היה אפשרי.

דוגמה: תפקיד דייר רשאי לפתוח את הלובי. עוצר הזמנות עדיין יכול
לעצור קישור אורח בשעה 02:00 מבלי לשנות את תפקידו של אף אחד.

שלוש רמות של מדיניות

1. ארגון – קומה עבור חברה או עץ בעלי נכסים
   ("הזמנות אורחים אינן ניתנות לשימוש בין השעות 22:00–06:00").
2. אינטגרציה – חיבור אחד
   ("בחיבור שער זה, רק מנהלים רשאים לשתף משתמשים").
3. מכשיר – הקופסה הפיזית, מוגדרת על ידי בעל החומרה המאומת,
   מחייבת כל ארגון שהצביע על אותו שער.

בתוך עץ ארגוני, ההגבלה ביותר מנצחת. מדיניות מכשיר חזקה עוד יותר,
ועדיין מגבילה בלבד – למעט יציאת חירום חופשית, אשר רק מונעת
מ-OpenApp לדחות פתיחות נכנסות (לא שחרור אזעקת אש).

חומרה משותפת זקוקה למנהל

לשערים מחוברים לרשת יש מצב כשל שמפתחות מעולם לא הכירו: כל מי שיכול להגיע
למכשיר יכול לשלב אותו.

מספר דיירים עשויים לחבר כל אחד את אותו שער קהילתי למרחב העבודה שלהם
ולחלק הזמנות. כל ארגון נראה "תקף". האדם האחראי על השער איבד את העלילה.

מדיניות ברמת המכשיר מאפשרת למנהל חומרה מאומת להגביל שיתוף או עוצר
בכל ארגון המשתמש בקופסה זו – מבלי לדרוש את שיתוף הפעולה שלהם.

החזקות: השאר פתוח, או השאר סגור

מנהל מורשה יכול להחזיק דלת:

• פתוחה (לדלג על סגירה אוטומטית) לחלון זמן או לוח זמנים חוזר
• סגורה (להתעלם מפקודות פתיחה) עם סיבה שאורחים יכולים לראות

החזקות הן תפעוליות, לא דלת אחורית סודית. מדיניות יכולה להגביל את משך ההחזקה,
לאסור החזקות קבועות, או לאסור החזקה פתוחה לחלוטין.

אם שתי דלתות חולקות פותחן, הן חולקות את ההחזקה. המציאות היא חשמלית.

מה קורה כשמישהו פותח

1. הם משתמשים בפורטל (סריקה, הקשה, קישור) או בפעולת אפליקציה מורשית.
2. OpenApp מזהה את הפורטל לדלת ולפותחנים שלה.
3. היא בודקת זהות: דייר של יחידה מורשית, הזמנה תקפה, או לא.
4. היא בודקת הגבלות דלת (כל הדיירים לעומת רשימה לבנה של יחידות).
5. היא בודקת מדיניות (עוצר, החזקות, מגבלות קצב).
6. אם מותר, היא שולחת פקודת פתיחה לפותחן – ומתעדת את הניסיון.

ההרשאה היא צד שרת. כתובת URL חכמה אינה מפתח ראשי.

ביקורת היא חלק מהגישה, לא צילום מסך

אתם אמורים להיות מסוגלים לענות "מי פתח מה, מתי", כולל דחיות.

OpenApp שומרת יומן ביקורת מסוג "הוספה בלבד": מפעילים סוקרים אותו בלוח המחוונים,
מערכות יכולות למשוך אירועים אחרונים, לייצא היסטוריה, או לקבל Webhooks חתומים.

כך מלון, משרד או קמפוס מתייחסים לכניסה כאל
פעולה בת-אחריות – לא כאל אווירה.

אינכם לכודים בלוח המחוונים

לוח המחוונים הוא הדרך שבה בני אדם מנהלים אתר.

אותן יכולות זמינות כ:

• API HTTP ציבורי
• ערכות SDK רשמיות
• סקריפטים של OpenApp לאספקה חוזרת

תוכנות נכסים, הזמנות וקמפוס נשארות אחראיות על התיעוד שלהן. הן
קוראות ל-OpenApp כאשר שהייה מתחילה, סטודנט נרשם, או תא צריך
להיפתח.

חומרה ותוכנה מופרדות בכוונה

אתם בוחרים פותחנים לפי פתח ולפי תקציב: מבקרים בעלות נמוכה מאוד ועד
ציוד מסחרי עם ענן ספק משלו.

OpenApp נשארת מישור הבקרה, ממשקי ה-API והחוויה העקביים.

זה ההפך מ"קנו את משפחת הקוראים שלנו, ואז תוכלו לקבל תוכנה".

מודולריות אינה סיסמה כאן. זו הדרך שבה תיק עבודות מעורב שורד מגע
עם המציאות.

מוצר אחד לפתיחה, שיחה ואורח

רוב הערימות מפוצלות:

• גישה
• אינטרקום
• אישורי אורחים

OpenApp מתייחסת אליהם כאל הגעה אחת:

• השלט הוא ההתחלה
• הספרייה היא הדרך שבה זרים מוצאים אדם
• ההזמנה היא הדרך שבה אתם מדלגים על האדם כשאתם כבר בוטחים בביקור
• הפותחן הוא הסנטימטר האחרון

פחות קונסולות. משטח מדיניות אחד. סיפור ביקורת אחד.

זהות ממוקדת הרשאות

זהות היא גלובלית. הרשאה היא מקומית ומצטברת.

זה מאפשר:

• אנשים מרובי ארגונים ללא כפילויות אנושיות
• האצלה לכל דירה מבלי להפוך כל דייר למנהל בניין
• הזמנות שאינן "משתמשים" מזויפים ששכחתם למחוק

רוב מוצרי הגישה עדיין מתחילים מ"אדם זה שייך לדייר זה".
בניינים לא.

הפורטל הוא אובייקט יציב

דלתות נכשלות. ממסרים מוחלפים. אינטגרציות נוצרות מחדש.

מזהה הפורטל על הלוחית הוא הדבר שהצוות יכול לתת לו שם: "סרוק לובי".

פורטלים רבים יכולים להצביע על דלת אחת (נתיב הולכי רגל מול נתיב רכב, שפות,
קמפיינים). דלת אחת אינה נאלצת להיות מדבקה אחת.

זהות ציבורית יציבה היא תכונה תפעולית המחופשת לכתובת URL.

ניהול מכשירים לעולם האמיתי

חומרה משותפת מחוברת לרשת אינה מקרה קצה. אלו קהילות מגודרות,
מגרשים מעורבים, ו"בן דודי חיבר את השער".

שכבת מכשיר מגבילה בלבד, בבעלות מנהל חומרה מאומת, היא הדרך שבה
OpenApp ממדלת פיזיקה ופוליטיקה – לא רק תרשימי ארגון.

מודל אחד, שבעה סוגי פריסה

הפלטפורמה זהה עבור:

1. בית פרטי
2. בניין דירות משותף
3. משרד (כולל חללי עבודה גמישים)
4. דירת נופש לטווח קצר
5. מלון
6. קמפוס
7. לוקרים / מטריצת חבילות

מה שמשתנה הוא מי אחראי, כמה זמן נמשכת הגישה, ואיזו
מערכת חיצונית היא מקור האמת. לא מוצר שונה לכל ברושור.

כיצד לקרוא מקרה שימוש

עבור כל צורה נציין:

• מי סובל אם הגישה שגויה
• איך נראה "טוב"
• אילו רכיבי OpenApp נושאים את המשקל

דוגמאות חומרה נשארות גנריות בכוונה. קטלוג האינטגרציות הוא
המקום למחברים ספציפיים – לא סיפור זה.

בית פרטי

מי: משק בית, אולי יחידת דיור שאתם גרים בה.

כאב: אפליקציות ספקים, קודי אורחים על פנקס, שער שלא מתקשר עם
הדלת.

טוב: קומץ אנשים, אורחים מזדמנים, פורטל על השער או
הדלת הקדמית, הזמנות שפג תוקפן.

Virtual Access עדיין עוזר: ערך אחד בספרייה יכול להיות "בית", והחניה
יכולה להיות פורטל שני. קטן לא אומר כאוטי.

שערים משותפים לקהילה ולרכבים

מי: רחוב, מתחם, עמותת חניה.

כאב: שער אחד, משקי בית רבים, כל אחד ממציא רשימת אורחים משלו.

טוב: פורטל נתיב (QR, NFC, סימניה ברכב), הזמנות עם עוצר,
ומנהל חומרה כך שהשער לא יוכל להיות משותף מחדש בשקט לנצח.

שלטי הולכי רגל ושלטי רכב יכולים להיות פורטלים שונים לאותו
פותחן. המכונית אינה זקוקה לפילוסופיה ייחודית של גישה.

בניין דירות משותף

מי: דיירים, צוות בניין, מבקרים, משלוחים.

כאב: פאנל לובי מיושן, פובים לכל שינוי, אין שליטה לכל דירה.

טוב:

• אינטרקום וירטואלי בשלט הלובי
• כל דירה יכולה לנהל את האנשים שלה
• מנהלי בניין עדיין רואים את כל האתר
• שער חניה ודלת הולכי רגל במקום אחד

זו הצורה שבה האצלה אינה מותרות. היא המוצר.

האצלה, במונחים אנושיים

מנהל הבניין לא צריך להיות מסד הנתונים של השותפים.

מנהל דירה יכול להוסיף או להסיר אנשים עבור יחידה זו, לבחור מי
מקבל שיחות מבקרים, ולהזמין אורחים לדלתות שיחידה זו רשאית להשתמש בהן.

מנהל הבניין עדיין מחזיק בפורטלים, במדיניות ובפתחים עצמם.

פיצול זה הוא הדרך שבה בניין בן 60 יחידות נשאר תפעולי ללא
פקיד גישה במשרה מלאה.

משרד וחלל עבודה גמיש

מי: צוות, חברים, לקוחות מבקרים, מנקים.

כאב: דלתות פנימיות רבות; ביקורת; חברים שמתחלפים מדי שבוע; קבלה ש
אינה יכולה להיות צוואר בקבוק.

טוב: ניהול מרכזי, פחות פוליטיקה לכל יחידה, תיעוד חזק,
פורטלים בדלת הרחוב ובדלת הסוויטה.

אם אתם כבר מפעילים מערכת מקום עבודה, OpenApp צריכה לקבל "חבר זה
תקף עד יום חמישי", לא להפוך למסד נתונים שני של משאבי אנוש.

דירת נופש לטווח קצר

מי: אורחים שמעולם לא היו בבניין; מפעיל מרוחק.

כאב: מותגי מנעולים שמניחים בריחים זהים; שערי חניה; צ'ק-אין
ב-16:00 באזור זמן אחר.

טוב: מערכת ההזמנות נשארת מקור האמת. באישור,
אוטומציה יוצרת הזמנה לחלון השהייה. ביציאה, היא מסתיימת.
האורח משתמש בקישור – אין צורך באפליקציית דיירים.

פותחנים מעורבים לכל רישום הם נורמליים. ההזמנה לא מתייחסת לכך.

מלון (כולל בוטיק)

מי: אורחים, דלפק קבלה, ניקיון, מבקרים בלובי.

כאב: PMS יודעת את השהייה; הלובי הוא ספק אחר; החניה היא
שלישית.

טוב: צ'ק-אין יוצר גישה מוגבלת בזמן לפתחים שתבחרו;
ספריית הלובי מתקשרת לדלפק או לחדר; שערים משתמשים באותו סיפור הזמנה.

מגבלה כנה: מערכות אקולוגיות של אישורי מנעול חדר מומחים יכולות להישאר
במקום. OpenApp משלימה לובי, היקף וקישורי אורחים. היא לא צריכה
להתיימר להיות מקודד פס מגנטי.

קמפוס

מי: צוות, סגל, סטודנטים, הורים, מבקרי אירועים, בניינים רבים.

כאב: ארגונים מקוננים; אוכלוסיות מעורבות; מערכת סטודנטים ש
כבר יודעת הרשמה.

טוב: תת-ארגונים, מנהלים מואצלים, זרימות אורחים לאנשים ש
אינם בספרייה מדי יום.

מערכת המידע לסטודנטים נשארת סמכותית לגבי "האם אדם זה רשום". OpenApp סמכותית לגבי "האם הם רשאים לפתוח דלת זו הלילה".

לוקרים ומטריצת חבילות

מי: נמען, שליח, מפעיל חדר דואר.

כאב: קיר של קופסאות שחייבות להיפתח אחת בכל פעם, קשורות לתהליך
איסוף – לא לספריית לובי.

טוב: כל תא הוא ישות. תהליך העבודה שלכם מאמת קוד,
ואז OpenApp פותחת ישות זו.

אותו מודל פעולה כמו דלת. טקס אנושי שונה. אין צורך ב"מוצר לוקרים" נפרד
למישור הבקרה.

שימוש מעורב אינו מקרה מיוחד

פודים עם חנויות, דירות מעל, אגף מלון וחניה משותפת הוא
בדרך כלל כמה מהשקפים הקודמים בבת אחת.

ההימור של OpenApp: אל תמציאו מוצר שמיני. הרכיבו:

• ספריות לכל בניין
• פורטלים לכל פתח
• ארגונים לכל מפעיל
• הזמנות לכל שהייה או ביקור
• מדיניות מכשיר בשער המשותף

אם המודל היה עובד רק עבור ברושור אחד, שימוש מעורב היה שובר אותו. שימוש מעורב
הוא המבחן.

סיפור: מבקר בלובי

1. הם ניגשים. יש שלט, לא פאנל מת.
2. הם סורקים. הם רואים יחידות, לא ספר טלפונים של מספרים פרטיים.
3. הם מתקשרים לדירה 12. הטלפון של מאיה מצלצל כמו שיחת טלפון.
4. היא רואה מי שואל. היא יכולה לדבר, ואז לפתוח – או לסרב.
5. הניסיון מתועד.

אף אחד לא הדפיס פוב לאורח חד פעמי. אף אחד לא צלצל לכל הבניין.

סיפור: דייר חוזר הביתה

1. הם התחברו פעם אחת.
2. הם מקישים על אותו שלט לובי (או NFC בשעון).
3. הם מקבלים פתיחה, לא את הספרייה.
4. פתיחה אוטומטית אופציונלית: הסשן יכול להפעיל את הפותחן בעת הטעינה, אם הם
   בחרו בנוחות זו.

השלט לא השתנה. ההרשאה השתנתה.

סיפור: אורח לשהייה

1. ההזמנה מאושרת. אוטומציה יוצרת הזמנה לחניה ולדלת היחידה,
   תקפה מיום שישי 16:00 עד יום שני 11:00.
2. האורח מקבל קישור. הוא לעולם אינו יוצר חשבון.
3. לאחר שימוש ראשון, סריקת שלט החניה היא הקשה על פתיחה.
4. ביום שני 11:01 זה נפסק. אף אחד לא אוסף כרטיס מתיבת מפתחות.

אם הם מגיעים ב-02:00 ומדיניות עוצר אוסרת כניסה בהזמנה, הקישור עדיין
"תקף" – ועדיין נדחה כהלכה עד הבוקר.

סיפור: יום שלישי של המפעיל

• הוספת דייר שזה עתה חתם על חוזה שכירות
• החזקת רציף ההעמסה פתוח לחלון זמן משלוח
• צפייה בדחיות של אמש
• החלפת פותחן תקול מבלי לשנות את לוחית הלובי
• הזמנת מנקה ליום חמישי 09:00–12:00

לוח המחוונים נבנה עבור זה. ה-API נבנה עבור מקרים שבהם יום שלישי קורה
אלפיים פעם.

מה אדריכל פתרונות בוחר בפועל

לא "איזו אפליקציה יפה". אלא אילו אילוצים:

• מה כבר נפתח, ומה חייב להישאר כגיבוי
• אינטרקום מבוסס טלפון בלבד לעומת פאנל קווי שתשמרו
• מי הוא מקור האמת עבור אנשים (PMS, קמפוס, גיליון אלקטרוני)
• היכן האצלה חייבת להתקיים (דלפק קבלה מול כל דירה)
• כיצד שערים משותפים מנוהלים
• כיצד תוכיחו גישה מאוחר יותר

OpenApp מתאימה כאשר אילוצים אלה מעורבים. היא אופציונלית כאשר ספק יחיד
כבר מחזיק בכל האתר ואתם אוהבים זאת.

טלפונים ורשתות נכשלים

תכננו עבור סוללות מתות, אין קליטה, ו"אין לי את האפליקציה".

פתרונות טיפוסיים:

• מפתחות מכניים לאנשים מוגדרים
• חומרת יציאה מדורגת ולחצן יציאה
• קבלה או אינטרקום מדור קודם שנשמר בשירות
• לוחות זמנים בענן ספק או במכשיר שאינם תלויים ב-OpenApp

OpenApp צריכה להיות נתיב מודרני חזק, לא הנתיב היחיד, עד שה
בניין יקבל במפורש חיים מבוססי טלפון בלבד.

הנתיב המקביל החלש ביותר מנצח

אם תוסיפו לוח מקשים עם 1234 ליד זרימת טלפון חזקה, תוקפים ישתמשו
בלוח המקשים.

שיטות נוספות הן בחירות מקבילות עבור האדם שאינכם רוצים.
נוחות יכולה להוריד את האבטחה האמיתית של הפתח.

שמרו פובים מדור קודם אם אתם חייבים – אך התייחסו אליהם כחלק ממודל האיומים, לא כ
נוסטלגיה בלתי מזיקה.

הציות הוא באחריותכם

OpenApp מתזמרת. היא אינה מאשרת את יציאת האש שלכם, נגישות,
או קוד בקרת גישה מקומי.

Fail-safe לעומת fail-secure, חשמל, והמנעול המכני הם באחריות המתקין ו
המפעיל. תוכנה אינה יכולה להוות תחליף להתקן יציאה רשום.

קראו זאת ככבוד לעולם הפיזי – לא כהתנערות.

מה OpenApp אינה

• לא יצרנית מנעולים
• לא פלטפורמת ניהול וידאו שמחליפה מערכת מצלמות
• לא מקודד "הכנס והפעל" לכל מערכת כרטיסי מלון
• לא תחליף לתכנון בטיחות חיים
• לא מערכת בקרת גישה רשומה לאש, דלתות מילוט, או UL / EN
• לא "רק אפליקציית ממסר" ללא אנשים, מדיניות ותיעוד

היא מישור בקרת הגישה: זהות, פתחים, הזמנות, אינטרקום,
מדיניות, ביקורת – על חומרה שאתם בוחרים.

אם תזכרו שישה דברים

1. דלת היא החלטה עם תיעוד.
2. רוב הכאב הוא פיצול, לא מחסור במנעולים.
3. OpenApp היא מישור בקרה; פותחנים הם תוספים.
4. הפורטל הוא האובייקט היציב שעל הדלת.
5. תפקידים מעניקים, מדיניות מגבילה; זהות היא אדם אחד עם הרשאות רבות.
6. אותו מודל מכסה מבית ועד קמפוס ולוקרים – כולל שימוש מעורב.

תיעוד כתוב, לפי תפקיד

• ראו איך זה עובד: תחילת עבודה, והגדרת בקרת גישה
• יום-יומי: מדריך למשתמש (פורטלים, אינטרקום נייד)
• תכנון האתר: ארכיטקטורת בקרת גישה, מדיניות, גיבוי
• מדריכי מגזר: דירה, דירת נופש לטווח קצר, מלון, לוקרים
• חיבור חומרה: קטלוג אינטגרציות
• אוטומציה: תיעוד API, ערכות SDK, סקריפטים של OpenApp

מצגת זו היא ההתמצאות. דפים אלה הם המדריכים.

נושאים שנוכל להעמיק בהם מאוחר יותר

כל אחד מאלה יכול להיות הרצאה בפני עצמה:

• פורטלים, NFC, כלי רכב ופתיחה אוטומטית
• אינטרקום וירטואלי ואפליקציית הטלפון המקורית
• מדיניות, עוצרים, החזקות וניהול מכשירים
• האצלה בדיור רב-יחידות
• הפעלת OpenApp ממערכות PMS / הזמנות / קמפוס
• ביקורת, ייצוא ו-Webhooks
• פשרות אדריכליות: קישוריות, עלות לדלת, גיבוי

המפה נמצאת כאן כדי שלהרצאות אלו יהיה מקום להיתלות.