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

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

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

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

מבקר בלובי

כל צד של השיחה

דייר חוזר הביתה

אורח לסוף השבוע

מה מציג הטלפון של האורח

יום שלישי של המפעיל

ארבעה רגעים, דפוס אחד

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

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

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

שאר המצגת הזו מסבירה את הרעיונות שמאחורי מה שראיתם זה עתה.

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

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

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

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

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

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

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

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

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

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

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

OpenApp ממוקמת במקום שבו זהות תוכנה פוגשת פעולה פיזית.

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

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

מישור בקרה בענן, והשריר שהוא מניע

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

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

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

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

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

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

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

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

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

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

החלף מהיסוד, או תקוע עם שאריות

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

אורחים ומשלוחים קודמים

פתיחה ושיחה הפכו למוצרים נפרדים

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

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

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

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

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

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

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

בבניין כבר קיימת תוכנה

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

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

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

מפתחות מכניים, תגי קרבה, ובקר מקומי

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

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

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

תוכנת ביניים למנעולים ועשה זאת בעצמך

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

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

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

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

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

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

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

OpenApp מתחילה שם.

OpenApp בפסקה אחת

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

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

אינך צריך להחליף מהיסוד

בכל פעם שזה מעשי, כדאי להשתמש מחדש במה שכבר נפתח:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

גישה וירטואלית היא מודל הבניין

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

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

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

המדריך: ערכים שאנשים יכולים למצוא

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

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

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

מבקרים אנונימיים רואים מדריך, לא מאגר של נתוני קשר פרטיים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה ששונה, בטבלה אחת

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מודל אחד, שבע צורות

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

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

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

בית פרטי

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

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

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

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

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

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

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

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

השכרה לטווח קצר

מלון, כולל בוטיק

קמפוס

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

שימוש מעורב הוא המבחן

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

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

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

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

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

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

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

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

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

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

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

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

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

הציות הוא שלך

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

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

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

לכל פתח יש סיווג בטיחות חיים

לפני ש-OpenApp פותחת דלת בייצור, מישהו מציין מהי הדלת:

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

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

מה OpenApp אינה

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

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

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

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

לאן להמשיך

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