זמן אמיתי

זמן אמיתי

REAL TIME

כל הזכויות שמורות לנציבי בן-אמוץ, חיפה, ישראל.

מה זה זמן אמיתי

מה זה זמן אמיתי? האם יש זמן מזויף?

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

חוץ מזה, למחשב לוקח זמן לעשות את החישוב. מחשב קטן ואטי יחשב זאת תוך 0.1 שניה, למשל, ומחשב מהיר יחשב זאת תוך 0.001 שניה. אין קשר ישיר בין הזמן שלוקח למחשב לחשב את התוצאה, ובין הזמן שאורכת התופעה במציאות, מחוץ למחשב, ובמקרה הנ"ל אין קשר לזמן בו האבן נופלת.

אבל יש מקרים בהם יש קשר בין הזמן בעולם החיצוני ובין זמן החישוב במחשב. תיכנות במקרים אלו נקרא תיכנות לזמן אמיתי (REAL TIME).

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

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

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

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

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

תצוגה בזמן אמיתי

כאשר הגיעו מחשבי ה-PC החדשים, עם 4Mb זכרון, הוחלט להשתמש במחשבים כדי לאגור את תוצאות הניסוי ב-3 ה-Mb הנוספים, לבדיקה מאוחרת יותר. זה תיכנות לזמן אמיתי במעגל פתוח. היות וכתיבה על הדיסק הקשיח אורכת הרבה יותר זמן מאשר ה-LOOP מאפשר, הנתונים נאגרים בזמן הניסוי בזכרון המחשב, ורק אחרי גמר הניסוי, נכנס לפעולה המשך התוכנית, הכותב את התוצאות על הדיסק הקשיח, לשימוש מאוחר יותר. תוכנית המחשב נכתבה ב-TURBO-PASCAL . ( WINDOWS של אז, עוד בלי מספר גירסה, לא התאימה, כי בה רצים כמה דברים במקביל).

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

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

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

RTFM (Read The Fucking Manual)

מחשבי ה-386 היו אז החידוש האחרון, עם זכרון של 4 Mb, אבל נתקעו כל הזמן. רציתי לקרוא את ה-MANUALS של המערכת לניהול הזכרון, אבל היתה בעיה: היה עותק אחד, ארוך, והיתה הוראה מנהלתית לחסוך בצילומים, ולא קבלתי אישור לצלם את ה- MANUAL...

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

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

התברר שחלק מהזכרון ב-Mb הראשון מוקדש להעברת נתונים לזכרון העליון שמעל 1 Mb. בדיוק על כתובות אלו בזכרון אנשי האלקטרוניקה שמו את כרטיס ה-REAL-TIME.

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

מעודד מכך שמצאתי ב- MANUAL משהו רלוונטי, החלטתי להתלבש על ה- MANUAL של ה- TURBO-PASCAL, בו נכתבו התכניות. התברר לי שגירסה מתקדמת זו של TURBO-PASCAL כללה שיכלול, בו ה- TURBO-PASCAL השתמש אוטומטית בכל הזכרון הפנוי. היתה אפשרות להורות ל- TURBO-PASCAL לא לנצל שטחי זכרון פנויים ב-Mb הראשון. הנחתי שה- TURBO-PASCAL לא זיהה את השינוי בזכרון הסטנדרטי שעשיתי, או את מציאות כרטיס ה- REAL TIME. הוספתי את הפרמטר האוסר על ה- TURBO-PASCAL לחפש זכרון פנוי ב-Mb הראשון, והרצתי. מספר "התקעויות" המחשב ירד פלאים. במקום כל כמה דקות, לפעם בשבוע בממוצע. כנראה היתה תקלה גם במחשב עצמו, למרות שהיה מפירמה מאוד יוקרתית.

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

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

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

גרף של פרמטר נמדד אחד, מוצג בזמן אמיתי

כשנפתרה הבעיה של נפילות המחשב החדש 80386, יכולתי לגשת לפיתוח הגרפיקה ב-REAL-TIME.

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

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

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

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

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

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

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

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

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

מה שעשיתי היה שכל עוד לא הושלם שירטוט הגרף אחורה בזמן, כל 10 LOOPS חולקו כך: LOOP אחד מה-10 נועד לחישובים, חלק מה- LOOPS נועדו לשירטוט הנקודות הנמדדות באופן שוטף, ושאר ה- LOOPS נועדו לשירטוט נקודות אחורה בזמן, מתוך הנקודות שנאגרו בזכרון. תוך כ-שניה השירטוט אחורה בזמן הושלם, והשירטוט השוטף עבר לפעולה הרגילה, כפי שהוסבר בפרק 4 לעיל.

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

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

6. הפתעות בניסוי

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

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

כאשר רק החלו להתקבל התוצאות, בא מהנדס מכונות של הפרויקט, ושאל אם נוכל להגדיל את תדירות הדגימה פי 10! ז"א שה- LOOP הדחוס, יצטרך להיות קצר פי 10.

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

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

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

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

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

ואז - בפעם היחידה בחיי - הגיע אלי לעבודה קריאה לתרגיל מילואים.

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

בימים שאחר-כך הצלחתי לקצץ בתכנית המחשב כך שיכלה לרוץ פי 10 יותר מהר.

מה יצא מזה?

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

ומה יצא לי מזה?

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

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

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

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

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

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

החסכון ב-UPS הוא באמת "חסכון בכל מחיר".

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

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

ולמה לא אמרתי לבוס\ים? כי בכך יש כמה עבירות חמורות ביותר:

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

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

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

ד. רוב הבוס\ים פועלים למנוע הטרדות כמו א-ג מצד הפונה...

בחזרה לדף הקודם

מעבר לעבודה אחרת:

1. הוראה

2. תכנון צנרת

עבודות או ארועים שכללו תוכנת מחשב או שימושים במחשב (11 – 3):

3. כמעט הייתי HACKER

4. סימולציה נומרית במחשב

5. תכניות מחשב במנהרות הרוח

6. המחשב לעזרת מגדלי הזיקוק

7. המחשב המובטל