Smartlogic

אוטומציה ובקרה – איך מכינים HMI לבדיקת לוח בקרה

אוטומציה ובקרה – איך מכינים HMI  לבדיקת לוח בקרה בצורה הטובה ביותר

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

Electrical cabinets Testing 1

Electrical cabinets Testing 1

להדרכה בנושא איך גורמים ל HMI לעבוד עם הרשאות ווינדוס לחץ כאן

בקרה ואוטומציה ליט"אות -HVAC / AHU control

בקרה ואוטומציה ליט"אות -HVAC / AHU control

HVAC stands for Heating, Ventilating and Air Conditioning. AHU stands for Air Handling Unit.

HVAC and AHU control systems provide centralized monitoring and control of these systems, designed to maintain selected rooms in research and production facilities within specified pressure, temperature and humidity levels. This is achieved by operating and monitoring active components or actuators, and by monitoring environmental conditions, such as pressure, temperature and humidity, using corresponding sensors located in the HVAC and AHU system and the selected rooms.

Smartlogic has an extensive knowledge and experience in HVAC & Ahu systems.

The monitored values in HVAC and AHU systems and rooms are analyzed and processed by one or more controllers, such as programmable logic controllers (PLCs) or direct digital controllers (DDCs), which control the system accordingly in conjunction with an HMI installed on a PC connected to the PLCs or DDCs. The levels of the environmental conditions are compared to set-points (SPs) that are displayed and can be determined using human-machine interface (HMI) screens.

The level adjustments of the environmental conditions, such as pressure, temperature and humidity are performed using temperature control valves, electrical chillers and heaters, blowers, differential pressure switches, motorized flow dampers, etc. Fault switch, such as temperature, pressure and humidity switches, and fire alarm switches in HVAC/AHU systems provide alarm indications in case of failures.

The PLCs or DDCs currently used to control HVAC and AHU devices, such as valves, and heaters, receive analog and digital inputs from the sensors and devices installed in HVAC and AHU systems and, according to control logic, provide analog or digital outputs to control the devices.

An example of a device installed in HVAC and AHU systems, and controlled by PLCs or DDCs is a chiller.

Example – Chiller Control

A chiller is a machine that removes heat from a liquid via a vapor-compression or absorption refrigeration cycle. This liquid can then be circulated through a heat exchanger to cool air or equipment, as required.

Use in Air Conditioning

In air conditioning systems, chilled water is typically distributed to heat exchangers, or coils, in HVAC and AHU systems, or other type of terminal devices which cool the air in its respective space(s), and then the chilled water is re-circulated back to the chiller to be cooled again. These cooling coils transfer sensible heat (heat exchanged by a body thermodynamic system that has as its sole effect a change of temperature) and latent heat (heat released or absorbed by a body or a thermodynamic system during a process that occurs without a change in temperature) from the air to the chilled water, thus cooling and usually dehumidifying the air stream.

Use in Industry

In industrial application, chilled water or other liquid from the chiller is pumped through process or laboratory equipment. Industrial chillers are used for controlled cooling of products, mechanisms and factory machinery in a wide range of industries. They are often used in the plastic industry in injection and blow molding, metal working cutting oils, welding equipment, die-casting and machine tooling, chemical processing, pharmaceutical formulation, food and beverage processing, paper and cement processing, vacuum systems, X-ray diffraction, power supplies and power generation stations, analytical equipment, semiconductors, compressed air and gas cooling. They are also used to cool high-heat specialized items such as MRI machines and lasers, and in hospitals, hotels and campuses.

Chillers for industrial applications can be centralized, where a single chiller serves multiple cooling needs, or decentralized where each application or machine has its own chiller. Each approach has its advantages. It is also possible to have a combination of both centralized and decentralized chillers, especially if the cooling requirements are the same for some applications or points of use, but not all.

Decentralized chillers are usually small in size and cooling capacity, while centralized chillers generally have larger capacities.

Chilled water is used to cool and dehumidify air in mid- to large-size commercial, industrial, and institutional facilities. Water chillers can be water-cooled, air-cooled, or cooled by evaporation. Water-cooled chillers incorporate the use of incorporate cooling towers which improve the chillers' thermodynamic effectiveness as compared to air-cooled chillers. Chillers cooled by evaporation offer higher efficiencies than air-cooled chillers but lower than water-cooled chillers.

Water-cooled chillers are typically intended for indoor installation and operation, and are cooled by a separate condenser water loop and connected to outdoor cooling towers to expel heat to the atmosphere.

Chillers cooled by air and evaporation are intended for outdoor installation and operation. Air-cooled machines are directly cooled by ambient air being mechanically circulated directly through the machine's condenser coil to expel heat to the atmosphere. Machines cooled by evaporation are similar, except they implement a mist of water over the condenser coil to aid in condenser cooling, making the machine more efficient than a traditional air-cooled machine.

Smartlogic has an extensive knowledge and experience in HVAC & Ahu systems.

אוטומציה ובקרה – חיבור הציוד לתקשורת SATEC

אוטומציה ובקרה – חיבור הציוד לתקשורת SATEC

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

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

פורט תקשורת תומך בממשקים סטנדרטיים מסוג   RS-232 eia, RS-422 או RS-485 (לפי בחירת המשתמש או היצרן), שמאפשר חיבור למחשב,PLC* – Programmable Logic Controller או מודם.

התקשורת פועלת במתכונת אדון-עבד (Master-Slave), כאשר המחשב המארח (host) פועל כאדון והמכשיר הנשלט פועל כעבד, ז"א, המחשב משדר בקשות למכשיר שמגיב למחשב; אבל המכשיר לא משדר מידע למחשב ביוזמתו. המחשב המארח סוקר את המכשיר כדי לקבל נתוני מדידה, או כדי לקרוא או לתכנת את הפרמטרים בקונפיגורציה של ה- Powermeter.

חיבורים מסוג multi-drop

מכשירי SATEC ניתנים לשימוש ברשתות מסוג multi-drop. המכשירים מקושרים לרשת דרך פורטים לתקשורת מסוג RS-422 או RS-485. שני פורטים אלו הם סטנדרטיים לממשקים דיפרנציאלים סריאליים (serial differential interface standards). מכיוון שמשתמשים במד דיפרנציאלי, הרעש ברשת כמעט מושתק.

בסטנדרט RS-422, המכשירים מקושרים לרשת דרך שני זוגות חוטי חשמל, זוג אחד לצורך שידור והשני לקליטה (full duplex).

בסטנדרט RS-485, המכשירים מקושרים לרשת דרך זוג אחד של חוטי חשמל, כאשר הזוג הבודד משמש שידור וגם לקליטה (half duplex), ז"א, המשדר והמקלט של המכשיר מחוברים במקביל (in parallel).

הרשת מחוברת לפורט קישור (מסוג RS-422 או RS-485) של מחשב (או PLC) שמשמש כמארח מקומי (local host), או לפורט קישור מחשבי מסוג RS-232 דרך ממיר . RS-232של SATEC. ממיר זה תומך בעד 32 מכשירים ומספק גילוי נתונים אוטומטי automatic data detection)), ללא צורך ב-RTS  חיצוני. המרחק בין הממיר והמכשיר RS-232 יכול להגיע עד 15 מטר. ניתן לחבר מחשב שמשמש כמארח מקומי לרשת דרך ממיר RSC-232 ושני מודמים. הממיר והמודם הראשון מותקנים ביחד עם המכשירים, והמודם השני עם המחשב.

חיבורי תקשורת

ניתן לחבר עד 32 מכשירים לרשת תקשורת מסוגmulti-drop  RS-422/RS-485, שמורכבת מזוג כבלים עם זוגות חוטי חשמל מפותלים ומוגנים (עבור RS-485: 2 זוגות, אחד פעיל ואחד רזרבי; עבור RS-422: 3 זוגות, 2 פעילים ואחד רזרבי). האורך הכולל של הכבל יכול להגיע עד 1200 מטר.

הכבל מורכב מקטעים בין המכשירים. ציפוי ההגנה (shield) של כל קטע כבל מסוג RS-422/RS-485 חייב להיות מחובר לאדמה באחד מקצותיו בלבד. וודא שהפולריות נכונה כאשר אתה מחבר את הטרמינלים (+) ו- ( ) של כל פורט מסוג RS-422/RS-485.

חוטי החשמל בשימוש חייבים להיות בגדלים ביןAWG  22 ו- AWG 12 (mm2 3.30.3-).

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

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

רשת מסוג  multi-dropחייבת קונפיגורציה של נקודה-לנקודה (point-to-point configuration), ז"א, הטרמינלים (+) ו- ( -) של כל מכשיר חייבים להיות מחוברים לטרמינלים המתאימים של המכשיר הבא. מומלץ להשתמש בשיטת חיווט בקו ישר. חייבים להימנע מכל חיבור עם ענף בקו העיקריmain bus) ), כגון שיטות כוכב (star) ו-T  (tee); במקרים אלו יווצרו השתקפויות (reflections) של אותות שעלולות לגרום להתאבכות (interference) ראה איורים 1-4 (1-4Figures ).

כל נקודה סופית בקו העיקריmain bus) ) חייבת להסתיים עם נגד של1/4  ווט (Watt). נגדים אלו מצמצמים את השתקפויות Aעלולים לשבש את אותות הנתונים על הקו. נגדים אלו מחוברים בין הטרמינלים (+) ו- (- ) של המכשירים בכל קצה של הקו העיקרי. (כאשר משתמשים בממיר RSC-232 בחיבור למחשב, הנגד לא ישים מכיוון שהוא כבר מחובר בתוך הממיר). ערך הנגד חייב להתאים לאימפדנס הקווי (line impedance) של הכבל בשימוש, הערך האופייני נע בין 200 ו- 500 אוהם (Ohm).

רשתות תקשורת מסוג single-drop

מכשיר אחד יכול להתחבר למחשב מארח (computer host) אחד או לפורט קישור של מודם RS-232.

החיבור מחייב כבל עם זוגות חוטי חשמל מפותלים ומוגנים (3 זוגות: אחד פעיל, אחד מחודר לאדמה ואחד רזרבי). אורך יכול להגיע עד 15 מטר ניתן להאריך את המרחק הזה תוך שימוש בקצב שידור baud נמוך יותר, כבלים עם ציפוי ההגנה (shielded) או משחזר (repeater).

חוטי החשמל בשימוש חייבים להיות בגודלAWG  24 (mm2 0.5).

פרוטוקולים של תקשורת

כל מכשירי SATEC תומכים לפחות בשני פרוטוקולים: ASCII ו- Modicon Modbus RTU. שניהם פרוטוקולים פתוחים שניתנים לשימוש ע"י תוכנה של מארח ששייך לגוף שלישי  (third-party host-based software) נגישים לכל הנתונים ורגיסטרים של קונפיגורציה (registers configuration) של Powermeter.

מכשירים רבים של SATEC תומכים גם בפרוטוקול DNP3.0.

*סמארט לוג’יק משתמשת בבניית מערכות אוטומציה ובקרה בבקרים של חברת Siemens  וחברת אלן ברדלי – Allen-Bradley

דוגמאות ל- PLCs  בשימוש סמארטלוג’יק:

6XV1830-0EH10, 6ES7131-4BF00-0AA0, 6ES7193-4CA40-0AA0, 6ES7134-4GD00-0AB0, 6ES7193-4CA40-0AA0, 6ES7138-4CA01-0AA0, 6ES7193-4CC20-0AA0, 6ES7590-1AB60-0AA0, 6ES7511-1AK00-0AB0, 6ES7954-8LP01-0AA0, 6ES7155-6AU00-0BN0, 1746-NO4V, 1769-L16ER-BB1B

 

 

אוטומציה ובקרה – ISA-88

אוטומציה ובקרה – ISA-88

הגדרת ISA

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

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

הגדרת ANSI

American National Standards Institute –  ANSI הוא ארגון פרטי ללא מטרות רווח שמפקח על פיתוח תקנים מוסכמים בהתנדבות, עבור מוצרים, שירותים, תהליכים, מערכות וכוח אדם בארה"ב. ארגון זה גם מתאם בין תקנים אמריקאים ובינלאומיים, כך שמוצרים אמריקאים יוכלו להיות משווקים בכל העולם.

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

ISA88   פרסם סדרה של סטנדרטים על בקרת אצווה (batch control) עבור מערכות אוטומציה תעשייתיים. סטדרטים אלו משמשים בתכנון והפעלה של מערכות תעשייתית שונות.

לדוגמא: S88 , קיצור ל- ANSI/ISA-88, הוא סטנדרט שמתייחס לבקרה על תהליך אצווה (batch process) , מיועד לתיאור ציוד ותהליכים. זה לא סטנדרט לתוכנה, וניתן לשימוש גם לתהליכים ידניים

להלן הסטדרטים והתהליכים להן הם משמשים:

ANSI/ISA-88.00.01-2010 Batch Control Part 1: Models and Terminology

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

ISA-88.00.02-2001 Batch Control Part 2: Data Structures and Guidelines for Languages

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

ISA-88.00.03-2003 Batch Control Part 3: General and Site Recipe Models and Representation

מגדיר מודל למתכון כללי (general recipe) ולמתכון באתר (site recipe), הפעילויות שמתארות את השימוש במתכונים (recipes) אלו בתוך חברה ובין חברות, ייצוג של שני סוגי המתכונים, ומודל נתונים עבור שני סוגי המתכונים.

ANSI/ISA-88.00.04-2006 Batch Control Part 4: Batch Production Records

מספק הגדרה מפורטת עבור לרשומות של ייצור אצווה  (batch production records), וקובעים מודל ייחוס לפיתוח אפליקציות לצורך אחסון ו/או החלפות של  רשומות של ייצור אצווה . היישומים המבוססים על סטנדרט זה מאפשרים אחזור, ניתוח ודיווח של נתונים רשומים על ייצור אצווה  לפי בחירה.

Part 5: Implementation Models & Terminology for Modular Equipment Control

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

בסמארטלוג'יק אנו מתמחים בתכנון תהליך בתקן   S-88 מאפיון  Control-Modules דרך Equipment modules וכלה בפאזות תהליכיות. תוכלו לקבל שרותים המסתמכים על ידע וניסיון רב בעבודה עם מערכות מים, RO ,CIP, מזקקות, מערכות HVAC ,Utilities, ומודולים מוכנים סטנדרט S-88 שפיתחנו עבור מערכות אלו

Batch Control ANSI/ISA-88 -S-88 – בקרת אצווה

אוטומציה ובקרה – Batch Control ANSI/ISA-88 – S-88 – בקרת אצווה

הקיצור S-88  מסמל את התקן ANSI/ISA-88 – S88. תקן זה מתייחס לבקרת אצווה Batch Control, ומהווה גישה תכנונית לתיאור ציוד ותהליך תכנון. תקן זה לא נועד לתוכנה בלבד; אלא משמש גם לתהליכים ידניים. התקן אושר ע"י ISA  ב- 1995 ועודכן ב- 2010.

סמארטלוג'יק מתמחה בתכנון תהליך בתקן S-88 מאפיון  Control-Modules דרך Equipment modules וכלה בפאזות תהליכיות. שירותי החברה מסתמכים על ידע וניסיון רב בעבודה עם מערכות מים, RO ,CIP, מזקקות, מערכות HVAC ,Utilities, ומודולים מוכנים סטנדרט S-88 שפיתחנו עבור מערכות אלו.

הגדרת ISA

 International Society of Automation – ISA הינה אגודה טכנית ללא מטרות רווח, מיועדת למהנדסים, טכנאים, אנשי עסקים, מחנכים וסטודנטים, שעובדים, לומדים או מעוניינים באוטומציה תעשייתית ועיסוקים מקושרים לנושא, כגון מכשור.

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

הגדרת ANSI

American National Standards Institute –  ANSI הינה ארגון פרטי ללא מטרות רווח שמפקח על פיתוח תקנים מוסכמים בהתנדבות, עבור מוצרים, שירותים, תהליכים, מערכות וכוח אדם בארה"ב. ארגון זה גם מתאם בין תקנים אמריקאים ובינלאומיים, כך שמוצרים אמריקאים יוכלו להיות משווקים בכל העולם.

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

בקרת אצווה ANSI/ISA-88 – S-88

כללי

ועדת ANSI/ISA-88 פרסמה סדרת תקנים בנושא בקרת אצווה במערכות אוטומציה תעשייתיות.

תקן ,ANSI/ISA-88.00.01-2010, Batch Control Part 1: Models and Terminology מספק דגמים ומינוחים תקניים (סטנדרטיים) להגדרת דרישות בקרה עבור מפעלים שמייצרים אצוות.

תקן ANSI/ISA-88.00.02-2001, Batch Control Part 2: Data Structures and Guidelines for Languages,  מגדיר דגמים של נתונים(data)  שמתארים בקרת אצווה כפי שהיא משמשת במערכות אוטומציה תעשייתיות, מבני נתונים שמאפשרים קידום תקשורות פנימיות וגם בין יישומי בקרת אצווה שונים, והנחיות לגבי שפות שמייצגות מתכונים (recipes).

תקן ANSI/ISA-88.00.03-2003, Batch Control Part 3: General and Site Recipe Models and Representation,  מגדיר דגם עבור מתכונים כלליים ומקומיים; פעילויות שמתארות את שימוש המתכונים הכלליים והמקומיים במסגרת חברה אחת ובין חברות שונות; ייצוג מתכונים כלליים ומקומיים; ודגם נתוני מתכונים כלליים ומקומיים.

תקן ANSI/ISA-88.00.04-2006, Batch Control Part 4: Batch Production Records,  מספק הגדרה מפורטת עבור רישומי ייצור אצוות, וקובע דגם ייחוס לפיתוח אפליקציות לאחסנת ו/או המרת רישומי ייצור אצוות. יישומים מבוססים על תקן זה מאפשרים אחזור, ניתוח ודיווח של רישומי ייצור אצוות נבחרים.

ייעוד והיקף S-88

S-88 מיועד לאספקת תקנים והרגלי עבודה מומלצים לתכנון והגדרת מערכות בקרת אצווה בתעשיות עם בקרת תהליכים.

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

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

סמארטלוג'יק מבצעת פרויקטי אוטומציה ובקרה מודולארית למתקני יצור תוך שימוש בתקן S-88

אוטומציה ובקרה – תזמון הרצת סקריפטים בסימפליסיטי

אוטומציה ובקרה- מהי מערכת בקרה תעשייתית?

אוטומציה ובקרה – Industrial Control System – ICS  – מערכת בקרה תעשייתיות

מערכת בקרה תעשייתית היא מונח כללי שמתייחס לסוגים שונים של מערכות בקרה שמשמשים בייצור תעשייתי, כולל: מערכת בקרה לפיקוח והשגת מידע -Supervisory Control and Data Acquisition – SCADA, מערכת בקרה  מבוזרת – DCS – Distributed Control System – , וקונפיגורציות של מערכות בקרה קטנות יותר כגון בקרים עם לוגיקה שניתנת לתכנות – Programmable Logic Controllers -PLCs שנמצאים לעתים קרובות במערכים תעשייתיים ותשתיות קריטיות.

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

מערכת בקרה תעשייתיות לפיקוח והשגת מידע

Supervisory Control and Data Acquisition – SCADA – System

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

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

מערכת בקרה תעשייתיות מבוזרת

Distributed Control System- DCS

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

בקרת מוצרים ותהליכים מושגת בד"כ בעזרת חוגי בקרה עם הזנה אחורה – feed-back control loop – או הזנה קדימה – feed-forward control loop, כך שתנאי המוצר או התהליך נשמרות באופן אוטומטי תוך טווח מוגדר סביב ערך נתון (set point). השגת תנאי מוצר או תהליך במסגרת טווחים מוגדרים אפשרית רק בעזרת בקרים מסוימים הניתנים לתכנות.

בקר עם לוגיקה שניתנת לתכנות – PLCs

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

ולידציה – GAMP-Test Execution

GAMP- Good Automated Manufacturing Practice -Test Execution

After a test is written, reviewed, perhaps rewritten, and finally approved, it is then ready for execution.

Before commencing GAMP  tests using individual Test Cases or Test Scripts, pre-requisites for the test phase should first be verified and recorded. For example:

  • Test environment hardware (HW) (e.g., serial numbers and calibration certificates if required)
  • Test software (SW) (e.g., SW baselines)
  • Data sets
  • User accounts
  • Personnel involved (e.g., documentation of names, positions and sample signatures and initials)
  • Availability of baselined documentation (including, most critically, Test Documentation and Procedures)
  • Where applicable, calibration of critical instrument inputs

Manual Test Execution

Tests should be carried out as follows:

  • Any pre-requisites for the test should first be checked, as indicated above.
  • The test is then executed following the test instructions given within the Test Script.
  • Each test should be run and the test data collected as test results.
  • The tester decides whether the acceptance criteria have been met and records whether the test has passed or failed, and then signs and dates the test results. Sometimes, a third category 'refer for review', or 'conditional pass', or 'pass with observation' is used for cases where the tester feels that an independent opinion is required.
  • Supporting documentary evidence required by the Test Case or Test Script should be collated.
  • If an incident occurs, it should be recorded on a test incident sheet (or within the test incident system) and retained as part of the test record. The key to dealing with incidents during Test Script execution is to accurately record the incident and retain sufficient information to help with future problem solution.
  • It is helpful to maintain a test progress summary for recording overall test results and number of test runs. Depending on the company test policy, this summary may be regarded purely as a status and scheduling tool, or may form part of the post-execution review, and may be included in the Validation Report as a GxP document.
  • After completion of all tests or a group of tests (e.g., at the end of the day), there should be a review of the progress. A review group should assess all tests and incidents.

Possible actions for failed tests and incidents are:

  • Repeat the test.
  • Apply a change via change control and, if necessary, repeat the test.
  • Abandon one, several, or all tests.
  • Review the result, and upgrade it to a 'pass' status (with a record of the rationale for the change in status).

The review group should decide which course of action  to take and what retesting is required, and document the justification for the action(s). In my next post I will elaborate more on: Automated Test Execution (and Computerized Test Management Tools).

 

How to configure Modbus TCP to RTU converter HD67507

אוטומציה ובקרה

How to configure Modbus TCP to RTU converter HD67507

לחץ כאן למדריך מפורט של היצרן:

התקן מכאן במחשב .Net Framework 4

  1. הורד והתקן את תוכנה היצרן SW67507 מהלינק הזה.
  2. התחבר בכבל רשת אל מול הממיר וודא כי רשת אלחוטית בנייד כבויה
  3. נתק הממיר ממתח, הזז את ג'מפר boot configuration לימין כמו במדבקה וחבר שוב למתח.
    1. כל הנורות תתחלנה להבהב.
  4. חבר כבל הרשת בינך לממיר ותן את הכתובת סטטית הבאה למחשב שלך 192.168.2.100
  5. פתח התוכנה שהתקנת
  6. How to configure Modbus TCP to RTU converter HD67507
    How to configure Modbus TCP to RTU converter HD67507
  7. לחץ New Project, תן שם לפרוייקט

ולידציה – הבטחת איכות תוכנה – QA

והבטחת איכות תוכנה בפרט Quality Assurance – QA  – ולידציה

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

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

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

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

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

איכות התוכנה Software Quality

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

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

בתחילת הדרך, המבנה, הסיווג ולקסיקון התכונות וקנה המידה ביחס לתוכנה הופקו מהתקן ISO 9126-3 ובהמשך ממודל האיכותISO 25000:2005 . בהתבסס על הדגמים האלה, הגוף הבינ"ל Consortium for IT Software Quality (CISQ) הגדיר חמש תכונות מבניות רצויות להקניית ערך עסקי לתוכנה:

  • אמינות
  • יעילות
  • בטיחות
  • תחזוקתיות
  • גודל מתאים

הבטחת איכות תוכנה Software Quality Assurance – SQA

כללי

הבטחת איכות תוכנה מורכבת מאמצעים לניטור תהליכים ושיטות בהנדסת תוכנה שמבטיחים איכות זו. השיטות להשגת מטרה זו רבות ומגוונות, וחלקן כוללות דרישות לעמידה בתקו אחד או יותר, כגון 9000 ISO, או דגמים כגון CMMI)) Capability Maturity Model Integration. רבות מהן בד"כ בעזרת תוכנת אפליקציה במחשב אישי (PC – Personal Computer).

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

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

ה- PC מחובר ל-PLC  ע"י תקשורת מסוג Ethernet, RS-232 , RS-485 או RS-422. תוכנת האפליקציה מאפשרת כניסה ועריכה של הלוגיקה. בד"כ התוכנה מספקת פונקציות לניפוי באגים ואיתור תקלות בתוכנת ה- PLC. כמו כן, תוכנת האפליקציה תעלה ותוריד את תוכנת ה- PLC לצורכי גיבוי ושחזור.

פיתוח התוכנה

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

תוכנה יכולה להיות מפותחת מסיבות שונות. שלושת הסיבות הנפוצות הן:

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

פיתוח תוכנה משובצת (embedded software development) לבקרת מוצרי צריכה מצריך תהליכי פיתוח משולבים במהלך הפיתוח של המוצר הפיסיקלי המבוקר.