Smartlogic

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

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

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

Electrical cabinets Testing 1

Electrical cabinets Testing 1

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

ולידציה – Introduction to GAMP Test Environments

ולידציה – Introduction to Good Automated Manufacturing Practice (GAMP) Test Environments

The environment in which testing is conducted should be determined based on the life cycle output of the risk assessment. The following general principles apply:

  • The proposed test environment should represent as close as possible the production environment. The differences between the two should be detailed in the Test Specification or Protocol, and should be subject to impact assessment.
  • The test environment should be controlled and recorded to a level of detail that would allow it to be reconstructed if necessary. Such control includes:
  • System hardware (HW) and software (SW) components
  • Test HW (versions, serial numbers, as appropriate)
  • Test SW (version control of any simulations)
  • Test data (version control of any test data sets, test recipes, etc.)
  • Test user accounts
  • Where test HW/SW/data/user accounts are applied as they may appear in the production environment, controls should be available to ensure that they can either be removed cleanly or isolated from use (either logically or in time).
  • Where the test environment is required to undergo a temporary change to facilitate the execution of specific tests, both the change and its removal must be formally documented.

 GAMP Test Environments

In many circumstances it is undesirable to conduct all testing on the final production environment. Common examples include:

  • Non-availability of infrastructure at the point in the project life cycle when testing is carried out.
  • Non-availability of certain interfaces.
  • Requirement to test changes outside of the production environment prior to installation.
  • Requirement to carry out tests which may be destructive to the production environment.

 

The progression of SW build from a development environment through production environment depends on the risk priority associated with the system being installed or the change being made, and on factors such as the ease of possible modification removal from the system.

A change to a custom data processing module in a large business system may require progression from a development environment to a test environment, to a validation environment, and then to the production environment. This may be required because the change is a high risk priority, and, even if the if the original module could be restored easily, the test data may remain in the production environment.

Some tests, e.g., Performance Qualification (PQ), or part of it, may need to be conducted in the production environment.

 

 

בקרה ואוטומציה ליט"אות -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 שפיתחנו עבור מערכות אלו

אוטומציה ובקרה – מערכות SCADA ו- DCS

אוטומציה ובקרה – מערכות SCADA ו- DCS

שתי מערכות חשובות בתחום מערכות בקרה תעשייתיות Industrial Control System – ICS – הן:

  • Supervisory Control and Data Acquisition – SCADA
  • Distributed Control System – DCS

 

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

מערכת  SCADAכוללת בדרך כלל את התת-מערכות הבאות:

  • ממשק אדם-מכונה (HMI – Human-Machine Interface), שמציג מידע על התהליך למפעיל, וכך מאפשר למפעיל לנתר ולבקר את התהליך.
  • מערכת פיקוח, שצוברת מידע על התהליך ושולחת הוראות כדי לבקר את אותו תהליך.
  • יחידות מסוף רחוקות RTUs) – Remote Terminal Units ), שמתחברות לגששים (sensors), ממירים את אותות הגששים לנתונים דיגיטליים, ושולחים את הנתונים הדיגיטליים למערכת הפיקוח.
  • בקרים לוגיים שניתנים לבקרה (PLCs – Programmable Logic Controllers ), שמשמשים כמתקני שדה, מכיוון שהם יותר כלכליים, מגוונים, גמישים וניתנים לתצורה (configuration) מיחידות RTU בשימושים מיוחדים.
  • תשתית תקשורת, שמקשרת את מערכת הפיקוח ליחידות RTU.

 

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

 

ההבדלים העיקריים ביןSCADA  ו- DCS הם:

  • SCADAמותאמת להשגת מידע, בעוד ש- DCS מותאמת לבקרת תהליך.
  • SCADA מונעת לצורך אירוע (event), בעוד ש – DCS מונעת לצורך תהליך (process).
  • SCADA עדיפה לאפליקציות מפוזרות במיקומים גאוגרפיים נרחבים, בעוד ש- DCS משמש בד"כ לטיפול בתהליכים שמתנהלים במקום אחד.
  • SCADA אמורה לתפקד למרות תקלה בתחום התקשורת, בעוד שתחנות מפעילי ה- DCS תמיד מחוברות לכניסה/יציאה (I/O -Input/Output).

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

 

אוטומציה ובקרה – העלאת תוכנה מבקר סימנס

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

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

ולידציה – GAMP – Test Execution – part 2

GAMP -Automated Test Execution and Computerized Test Management Tools

As I've promised on my last post – Good Automated Manufacturing Practice (GAMP) Test Execution – part 1 I will now continue to elaborate on the execution of a test using automated (computerized) test tools. These tools should be conducted in accordance with the Test Plan or Strategy. This should require that all automated tools used to test GxP systems have been subjected to assessment and appropriate validation prior to their use, in order to establish s a high degree of assurance that they will perform as intended, and return accurate and secure results.

Before discussing the benefits and use of automated test tools, it is useful to describe the difference between a computerized test management tool and automated testing.

A computerized test management tool facilitates the task of Test Case and Test Script authoring, review and approval (pre and post execution), test execution, and test deviation management. This is accomplished using workflow enabled processes, electronic test artifact management (i.e., Test Cases, Test Scripts, Deviation Reports), and possibly electronic signatures.

However, even with computerized test management, the actual test execution is performed by the tester, even when this task is aided by the presentation of on-screen test scripts and electronic capture of test evidence. The tester must still manually follow the test steps, provide inputs to the system under test, and record the test evidence.

With automated test execution, the computerized test tool also executes the actual test and records the test evidence. This can significantly reduce the test execution time. Because most automated test execution is based upon initial manual test execution (where the tool often 'records' the manual actions of the tester), automated testing is most often used when executing tests during a second test cycle and is well sited to regression testing.

Benefits of Computerized Test Management Tools and Automated Test Execution

When planned properly, automating the test activities can bring considerable benefits within the project life cycle. However, if poorly planned, computer based tools and test automation may be difficult, complex, and time consuming task, with little or no return on investment.

Computerized test management tools can significantly reduce the amount of paper used during testing and provide helpful test management support. This includes the ability to report on the test activities status and facilitate test activities using workflow. In most large testing projects, the use of such tool can reduce testing timescales.

Not every aspect of a computerized system can be automatically tested. A key factor in the successful use of such tools is the early identification of the types of tests that should be automated, and the types of tests to be executed manually.

While computerized test management tools and automated testing can both provide benefits, they should be considered separately. Some project may benefit from the use of computerized test management tools, but may derive little benefits using automated test tools.

Before deciding on the usefulness of computerized test management and automated test tools, the following points should be considered:

Will the tools be used in a single project or more broadly within the organization? Typically in a large project or organization, a wide use is necessary to provide return on investment.

How many test cycles are typically executed, and how much regression testing is required? This will help determine the need for automated testing.

Will the tool be used by a dedicated test team, or in all projects? This has an impact on on-going administration and training requirements.

The use of computerized test management and automated test tools need to be regarded as a SW development activity that has its own life cycle. These tools will have their own implementation and validation life cycle. This will place additional requirements on the test team, particularly in terms of the skills required by test script developers.

The use of these tools is only effective if supported by adequate processes and if the staff has the necessary skills to use the tools effectively. The usability of a test tool is significantly enhanced if it is application-interdependent (i.e., used to test multiple application).

Easy maintenance of a test suite is crucial for a successful implementation of an automated test tool.

Automated test tools which include a version and configuration management can significantly improve the effectiveness and efficiency of retesting.

Features of Computerized Test Management and Automated Test Tools

Different test management and automated test tools are used In the IT industry, and the architecture of the application under test often determines the most suited tool. Most tools are purchased as configurable off-the-shelf SW packages, and the test team then configures the package locally to meet the particular usage required.

Before acquiring computerized test management tools or automated test tools, it is important that an organization understands and defines the requirements and form of use.

Test Management Tools

Test management tools may be classified into four general types:

General computerized test management tools

Developer-oriented tools

Functional test tools

Load and performance related tools

General Computerized Test Management Tools

Manage testing across the project.

Facilitates authoring, review and approval of Test Cases and Test Scripts, often using workflow and electronic signatures.

Allow developers, testers and project managers to track tests being run on various applications.

Trace tests back to their original requirements.

Summaries the defects found during the testing process.

The test management tools help to determine whether changes need to be made to the automated test tools themselves, as a result of changes to the applications being tested. However, they do not provide the facility to automate test execution.

Other tools do provide automated test execution (often integrated into the test management tools). The type of automated test execution tool depends to a large extent on the type of SW application under test and the type of test being executed. Three such tools are presented below

Developer-Oriented Tools

Are used in unit, component and module testing to address issues such as memory leaks or other early performance problems.

Are used to test specific pieces of the developer's application code independent of other units of code within the SW application.

May incorporate capture-replay utilities, which run sample tests against working versions of a program, capturing the activity it generates. During the playback phase, developers can see whether or not they are generating the results they expected.

Are particularly useful in testing large applications where different developers are working on different parts of the application.

Test that the code being developed is acting as expected.

Often contain keyword or table driven execution engines, which allow the development and execution of repeatable tests.

Often have scripting capabilities, allowing testers to modify their scripts to test additional items.

Can often be linked back to other packages providing Requirements Capture and Tracking capabilities, thus facilitating comprehensive requirements traceability.

Are particularly useful to test what happens to the code when multiple users access the application simultaneously, or transactions are required to be submitted, or responses are achieved in tight deadlines that manual testing could not reproduce accurately or consistently.

Are particularly useful for critical web based applications, because it is often difficult to predict the volatility of load change. Tools developed for this type of work can often drill down to lower levels of the code to find out where the bottlenecks are, and what is causing any delays.

These tools can also be valuable when testing the application scalability.

Functional Test Tool

Load and Performance Related Tools

Use of Computerized Test Management and Automated Test Tools

As stated above, Computerized Test Management Tools and Automated Test Tools can prove advantageous on large projects or within an organization. However, the use of such tools will require:

Use of testing procedures (SOPs or Work Instructions) for the activities supported by the tools, such as:

Test Case / Test Script authoring

Test Case / Test Script review and approval

Test execution

Test result review and approval

Test defect reporting

Test defect categorization

Test defect disposition

Test defect closure

Other activities, such as test planning and test status reporting, are less critical from a regulatory perspective and will not require formal procedures.

Users of the test tools that are properly trained in the use of the procedures.

Administration of the tool, including:

Configuration of the tool

Creation of test projects

Administration of users

Support and maintenance activities (backup and restore, capacity planning and performance monitoring, etc.)

Smartlogic ,when implementing test tools, initially defines the test processes to be supported by the tool(s). These test processes should comply with the testing good practices defined by GAMP, and the specific test policies and processes of the owning organization, which should define the requirements for using this tool(s).

All users of the test tools should be trained, not only in the use of the tools, but also in good testing practices.

When using test tools, clear user roles and responsibilities should be defined for each test process. Appropriate technical or procedural access restrictions should ensure that only authorized users are allowed to fulfill a defined role, and that the independence of the test process can be verified and enforced.

When used, computerized test management tools and automated test execution tools should provide the same level of test data integrity as an equivalent paper based process.

All these conditions and requirements can be facilitated through the use of features such as:

Role based authorities and user restrictions

Use of workflow to enforce test processes

Use of electronic or digital signatures

Secure, computer generated audit trails

Verification of Computerized Test Management and Automated Test Tools

The need to assure the security, integrity and availability of test data requires the appropriate selection and verification of the automated test tools (refer to GAMP 4, Appendix M4, section 4 for further details). Because such tools usually have only an indirect impact on product quality, they are considered low risk priority and do not require a detailed a lengthy validation process.

The verification of a computerized test management or automated test tools should focus on demonstrating that the tools are fit for purpose as far as critical requirements are concerned. The critical requirements that should form the basis of the tool verification are:

Security of the test data, facilitated by role based authorities and user restrictions, the use of electronic or digital signatures, and the use of secure, computer generated audit trails. Where the tools do not provide these features, the verification of the tool(s) should focus on establishing such security using logical or physical security controls, procedural controls and paper based audit trails.

Ability of the test tool to enforce defined test processes using workflow or equivalent controls. Where this is not possible, the verification of the tool(s) should focus on the ability of the tool to provide audit trail evidence of the test processes.

The scope of the verification activities may be scaled based upon risk, and should take into account the track record of the supplier and tools in the life sciences.

Test data managed within test tools would not usually be determined to be an electronic record within the scope of predicate rules, and the use of electronic or digital signatures would not usually be determined within the scope of predicate rules, so that the requirements of regulations such as 21 CFR Part 11 would not usually apply.

However, there may be cases where the SW or application tested using such tools is of greater regulatory significance, for example, where the SW or application is defined as a medical device or part of it. In these cases, a more formal validation of the test may be required:

The test record may also be determined to be an electronic record (i.e., an acceptance record under 21 CFR Part 820 Subpart H – Acceptance Activities).

Any associated signatures may be determined to be electronic or digital signatures (i.e., under 21 CFR Part 820.80).

The test management tools may need to comply with the requirements of 21 CFR Part 11, and other regulator guidance in electronic records and digital signatures