Smartlogic

Menu

מחבר: אביב צברי

ולידציה – Installation Qualification (IQ) Protocol

Posted on by אביב צברי

ולידציה – Installation Qualification (IQ) Protocol

Preparation Overview – part 1

The Installation Qualification (IQ) protocol is part of the validation documentation that covers the verification of the proper installation and operation of the system under validation in the user's facility. This IQ protocol is generic, and the system may include a PC with Human/Machine Interface (HMI), a Programmable Logic Controller (PLC), pressure, temperature and humidity transmitters, and other monitoring and control components designed to maintain the user's facility in proper environmental conditions.

The IQ protocol is designed to verify that the system under validation is properly installed and can be properly operated according to the supplier's requirements and the user's specifications. It must be reviewed and approved prior to the IQ performance.

                            Installation Qualification (IQ) Protocol Contents

The IQ protocol is structured in a relatively standard fashion, with predetermined chapters and sections, where the final contents are tailored according to the type and size of the system under validation.

:The IQ protocol includes the following chapters and sections

 Document Approvals – contains a table that lists the supplier's and user's personnel required to approve the protocol

Participants – contains a table with the supplier's and user's personnel that participate in the validation process and approve their participation

Responsibilities – lists the roles of supplier's and user's personnel responsible for writing and approving the protocol

Glossary – lists the acronyms used in the protocol

IQ Validation Approach – defines the scope of the IQ process, and the requirements for its successful completion

IQ Test Procedures – this is the main part of the protocol, and provides the description of the test procedures and the result tables for filling and approving the test results

IQ Approvals – contains a table with the user's personnel responsible for reviewing and approving the test results, summary reports and conclusions

Appendices – include validation deviation forms and the documentation list with all the documents and drawings relevant to the IQ process

This is the first part of  the preparation overview in Installation Qualification (IQ) protocol, the second part is  IQ Test Procedures which will be discus elaborately in our next article.

Hello world!

Posted on by אביב צברי

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

ולידציה – ספציפיקציה פונקציונלית

Posted on by אביב צברי

ולידציה – ספציפיקציה פונקציונלית (Functional Specification)

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

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

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

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

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

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

 

 

 

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

Posted on by אביב צברי

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

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

Electrical cabinets Testing 1

Electrical cabinets Testing 1

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

ולידציה – GAMP – Test Environments – Test Data Sets

Posted on by אביב צברי

ולידציה  Good Automated Manufacturing Practice – GAMP – Test Environments – Test Data Sets

Test data sets are often use where the test environment does no permit the use of real data for reasons of availability or confidentiality, or where the real data are not generic enough to cover certain test types (e.g., challenge testing at boundary conditions or stress testing).

                          Representative Test Environment

Test data should represent as close as possible the actual data to be operated on, in terms of volume and range of possible values (including invalid entries, to check that they can be correctly handled).

Differences between the proposed test data and the expected actual data should be detailed on the Test Specification or Protocol, and subject to impact assessment. If necessary, additional tests should be planned for the production environment in order to cover identified risk scenarios.

                         Control of Test Environment

Test data sets should be placed under configuration management and the version in use recorded.

For automatically generated data it may also be appropriate to control the utility used for generating the data, as well as the test data set

                         Removal from Production Environment

If the test data SW is added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well.

If the production environment includes automatic audit trailing, then it should be recognized that all audit trail entries from the testing process will remain.

                              Test User Accounts

Test user accounts are often used to permit testers to access the system at different levels, and ensure that activities carried out during testing are easily identified within any resulting audit trail.

                          Representative Test Environment

Where test user accounts are often used, these should be set up to represent each group of users within the system, including the corresponding authorizations. For multi-lingual system, test user accounts using foreign character sets should be included. Similarly, if existing individual accounts are used for testing, representatives from each group should be included.

                         Control of Test Environment

If test user accounts are used, then the setup of the accounts should be retained as part of the test documentation. Where there are issues of data confidentiality, controls should be exercised to ensure that the use of test accounts does not cause breaches of confidentiality.

                        Removal from Production Environment

If the test user accounts are added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well.

                            Test Documentation

The test environment includes documentation used during testing. This should always include the test documentation (Test Plans and Strategies, Protocols and Test Specifications, Test Cases and Test Scripts) and the controlling Design Specifications. It may also include operating procedures such as SOPs.

The test documentation should be controlled and recorded to a level of detail that would allow it to be retrieved as part of later review of the test results. This control would, at minimum, include the recording of current document version levels.

ולידציה – GAMP – Hardware & Software Test Environments

Posted on by אביב צברי

ולידציה –  GAMP – Hardware & Software  Test Environments

Good Automated Manufacturing Practice (GAMP) Hardware (HW) Environment Test

HW can be categorized according to both GAMP 4 HW category (standard or custom) and its function within the test environment. It can be one o f these three things

 Part of the system under test, i.e., part of the production HW

 Test HW representing part of the production environment, which may be needed because it is not feasible to include a certain element of the production system in the test environment

A separate test system, which may be used to represent an external system

          Representative Test Environment

As started previously, the HW environment should represent as close as possible the production environment

For example, if the test environment uses a standard network hub of the same type as the production environment, then the substitution probable introduces low probability if invalid test results in the production environment. If, however, the network cabling in the test environment is uses short patch cables, whilst the real environment has cable runs close to the maximum recommended length, there is clearly a possibility of different network behavior, and additional tests on site may be needed to prove proper network performance

                    Control of Test Environment

For standard HW (per GAMP 4 HW Category 1), the manufacturer's reference and serial numbers should be recorded.

For custom HW (per GAMP 4 HW Category 2), the version of the item and its controlling specification should also be recorded.

For all test HW, any applicable calibration status should be recorded in the context of the specific

                         Removal from Production Environment

If the test HW is added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well

Good Automated Manufacturing Practice (GAMP)  Software (SW) Environment Test

Test SW can also be categorized according to both GAMP 4 SW category and its function within the test environment:

Part of the system under test, i.e., part of the production HW

Test SW representing part of the production environment

A separate test system

              Representative Test Environment

The SW environment should represent as close as possible the production environment

For example, if the test environment uses a process controller of the same type as the production environment, then the substitution probable introduces low probability if invalid test results in the production environment. If, however, a particular interface is simulated in the test environment, a possibility remains that different timing factors or process dynamics could affect the operation in the production environment, and additional tests on the production interface may be appropriate

                        Control of Test Environment

For standard SW (per GAMP 4 SW Category 1, 2 or 3), the manufacturer's reference and version numbers (including installed patch cables) should be recorded. Any configuration or setup parameters should be controlled

For configured or custom SW (per GAMP 4 SW Category 4 or 5), the item should be placed under configuration management and the version in use recorded

              Removal from Production Environment

If the test SW is added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well

ולידציה –  GAMP – Hardware & Software  Test Environments

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

Posted on by אביב צברי

ולידציה – 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

Posted on by אביב צברי

בקרה ואוטומציה ליט"אות -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

Posted on by אביב צברי

אוטומציה ובקרה – חיבור הציוד לתקשורת 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

Posted on by אביב צברי

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