Smartlogic

Menu

תגית: אוטומציה תעשייתית

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

אוטומציה תעשייתית כוללת שליטה ובקרה של ביצועיי המערכות.

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

Posted on by אביב צברי

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

Posted on by אביב צברי

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

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

Posted on by אביב צברי

והבטחת איכות תוכנה בפרט 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) לבקרת מוצרי צריכה מצריך תהליכי פיתוח משולבים במהלך הפיתוח של המוצר הפיסיקלי המבוקר.

אוטומציה ובקרה – נקודות חשובות בעבודה בוורסה פרו

Posted on by אביב צברי

 אוטומציה ובקרה – נקודות חשובות בעבודה עם וורסה פרו

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

ביצוע FORCE בבקר ע"י קליק ימני על משתנה ו OVERRIDE

תפריט וורסה פרו

בשלב זה נתן לשנות את הערך ע"י TOGGLE או WRITE (במידה ומדובר בערך אנלוגי)

נקודות חשובות בעבודה בוורסה פרו – אוטומציה ובקרה

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

השרותים שלנו

  • תכנון והקמת מערך אוטומציית בקרה של מתקן יצור שלם.
  • יעוץ והדרכה לדרישות  21 CFR Part 11 .
  • יעוץ והדרכה לתקנים  S-88ו- S-95 .
  • בקרה ואוטומציה למערכות טיפול במים.
  • בקרות למערכות חימום, אוורור ומיזוג אוויר  (תמונה) (HVAC) תואמים את דרישות המנהל האמריקאי (FDA).
  • הכנת פרוטוקולי וולידציה.
  •  ניהול פרויקטי בקרה.

הגדרת כרטיס IF8U

Posted on by אביב צברי

על מנת להגדיר את הכרטיס IF8U  נצטרך לבצע את השלבים הבאים:

על מנת להגדיר את הכרטיס IF8U  נצטרך לבצע את השלבים הבאים:

1)      כדי להיכנס לתוכנת הבקר RS500  נלחץ עלIO configuration  .

2)      יפתח לנו החלון הבא – ונבחר בכרטיס  Other.

     

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

וזהו – סיימנו להגדיר את הכרטיס. אם נרצה להוסיף כרטיסים נוספים מאותו סוג נחזור על אותה הפעולה.

  • לגבי ה-scaling  של הכרטיס: ערך מקסימלי 20000 ערך מינימלי 4000 , ערך 21000 תקלת מכשיר וערך 3200 מסמן חיווט פתוח.

MicroLogix 1400 PID Tuning for AHU – בקרה ואוטמציה

Posted on by אביב צברי

בקר מיקרולוג'יקס 1400 מכיל 3 שלוש יחידות PID:

בקרת חימום:

עבודה מול TT-SP-0.1

ערכי PID

0.1-P

0.1-I

0.D-0

לולאה של שתי שניות

תנאי עבודה:

יציאת בקרת קירור שווה ל0

אין התראת TS

בקרת קירור:

עבודה מול TT-SP+0.1

ערכי PID

0.2 -P

0.1-I

0.D-0.

לולאה של שתי שניות

 תנאי עבודה:

יציאת בקרת חימום שווה ל0

בקרת לחות:

עבודה מול HT-SP

ערכי PID

0.2- P

0.1-I

0.D-0

לולאה של שתי שניות

 תנאי עבודה:

תמיד פועל

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

דוגמא להגדרות עבור PID :

מדריך אייפיקס למסד נתונים- IFIX TO SQL GUIDE

Posted on by אביב צברי

אוטומציה ובקרה איך משתמשים במסדי נתונים לאייפיקס -IFIX TO SQL GUIDE

Part 1

(In Control Panel, double click on Administrative Tools then double click on Data Sources(ODBC

If you have not already setup a System DSN then click on the System DSN folder.

Choose the ADD button, and select the applicable ODBC Driver:

If you will be using an SQL relational database then select the SQL Server driver:

Enter a Data Source Name.  This can be any name, and will be used later to connect to the relational database from FIX/iFIX.  Make a note of what is entered here.

Enter the Server Name then click the Next button.

Specify the information for how you want to verify the authenticity of the login; select "With Windows NT Authentication using the Network Login ID" if you want to use the existing logged on Windows operating system user to authenticate.

Click the Next button and complete the configuration information on the next two screens and then click Complete.

Test the connection to the specified database.

חלק 2

נכנסים לפרויקט פותחים את SCU בוחרים באייקון השני מימין sql accounts

לוחצים על add  בתיבת db type  בוחרים sql server  וב-db identifier בוחרים את השם שהגדרנו בחלק 1 (שם הבסיס נתונים) ואז לוחצים OK, לוחצים על configure sql task   לסמן enable  להזין db id  כמו בחלק 1 וב- sql cmd table  להזין SQLLIB  וב- error log table  להזין SQLERR לסמן את שתי הצ'קבוקס וללחוץ OK .ושוב OK.

לאחר מכן עדיין במסך SCU ללחוץ על אייקון שני משמאל alarm configuration  לבחור את alarm ODBC….  לסמן אותו enable ללחוץ עליו לחיצה כפולה וללחוץ configure..   ב- dbtype  לבחור sql server  וב- db id  לבחור את השם של הבסיס נתונים מחלק 1 לסמן את מה שמוקף באדום וגם את הצ'קבוקס התחתון ולבחור select all  לשים לב שהכתובת בשדה file נכונה כמו בתמונה

וללחוץ OK.

אוטומציה ובקרה -IFIX TO SQL GUIDE

המאמר נכתב על ידי אילן שעיה

 This article was written by Ilan Shaya, automation and control expert

ולידציה – תפקידים ואחריות בתכנון וביצוע בדיקות

Posted on by אביב צברי

מבוא

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

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

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

תפקידים בתוך צוות הבדיקה.

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

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

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

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

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

תפקידים בתוך צוות הבדיקה:

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

מנתח הבדיקה -Test Analyst- מחבר קובץ הבדיקה

test script –  מגדיר את קובץ הבדיקה , כולל את ההוראות המפורטות לבדיקת תחום פונקציונאלי ספציפי במסגרת הפרויקט.

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

בוחן קובץ הבדיקה – Test Script Reviewer

מוודא שכל הדרישות מולאו כמוגדר בקבצי הבדיקות.

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

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

בודק -Tester

מבצע את הבדיקות בהתאם לקבצי הבדיקות.

מודיע על כל חריגה למנהל -Incident Manager.

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

עד בדיקה– Test Witness

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

בוחן תוצאות הבדיקה – Test Result Reviewer

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

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

מוודא שכל החריגות נרשמו.

מאמת את כל תוצאות הבדיקות (מצב עבר/נכשל), בהתבסס על ההוכחות המתועדות.

מנהל הבדיקות – Test Manager

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

מוביל צוות הבדיקות– Test Team Leader

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

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

צוות תשתיות הבדיקה-Test Infrastructure Team

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

סגל טכני -Technical Staff

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

אדמיניסטראטור של צוות הבדיקות -Test Team Administrator

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

ניהול התיעוד.

עזרה בהקצאת משאבים ופעילויות של רישום זמנים.

רישום פרוטוקולים בפגישות רלוונטיות.

פעילויות אחרות מוקצבות ע"י מנהל הבדיקות.

 

  תפקידים מול צוות הבדיקה:

מפתח תוכנה – Software Developer

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

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

מנהל מקרים חריגים – Exceptions/Incidents Manager

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

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

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

אבטחת איכות / בקרת איכות – Quality Assurance / Quality Control – QC/QA

תפקיד זה יכול להתבצע ע"י מומחה לוולידציה של מערכות ממוחשבות או איכות טכנולוגית מידע ולמעשה ע"י אנשי אנשי צוות טכני מוסמכים מחוץ למחלקת  QC/QA:

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

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

מנהל הפרויקט – Project Manager

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

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

מנהל התוכנית – Program Manager

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

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

 בעל המערכת  – System Owner

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

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

 מבקר פנימי – Internal Auditor

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

אדמיניסטראטור המערכת – System Administrator

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

  במידה הצורך, יסייע לצוות הבדיקה במקרים של בעיות במהלך הבדיקה .

מנהל הקונפיגורציה  – Configuration Manager

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

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

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

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

צוות ניהול המידע – Data Management Staff

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

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

בדיקות קבלה – משתמש –Acceptance Testing

משתמשי המערכת אחראים בד"כ על הביצוע הסופי של בדיקות הקבלה (Acceptance Testing) ועל הגדרת קבצי הבדיקה (Test Scripts) עבור בדיקות הקבלה.

המשתמשים נתמכים ברוב המקרים ע"י ארגון בדיקה – Test Analysis and Testers.

ספק – Supplier

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

תוצאות הערכת הספק יכולות לשמש כעזר בהגדרת היקף הבדיקות.

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

 

פונקציות בסיסיות בסביבת עבודה של תוכנת Cimplicity

Posted on by אביב צברי

Cimplicity הינה תוכנת בקרה (scada) מבית היוצר של GE-General Electric.

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

דברים בסיסיים:

איך עושים שמסך ההתראות יקפוץ בכל התראה חדשה?

  • מגדירים תג חדש בשם ALARMֹI_IS_ON
  • ב-Event Editor מגדירים Event חדש מסוג: Alarm generate.
  • ב Action של ה Event  : Absolute SP -> Alarm_is_ON=1
  • יוצרים אוביקט במסך Objects.
  • באוביקט שיצרנו עושים תנאי ב- events -> if Alarm_is_on==1 -> OpenScreen Alarm.cim
  • שמים לינק בכל מסך לאוביקט הזה.
  • במסך התראות -> OnScreenOpen -> ALARM_IN_ON=0

תקלות:

לא רואים התראות במסך ההתראות

אפשרות מס' 1: בוצעו שינויים לא במצב דינאמי.

פתרון: יש לעשות stop ו start  לפרויקט.

 

אפשרות מס' 2: הפרוייקט לא מקושר למסך התראות.

פתרון: במסך ההתראות-> כפתור ימני על הOLE -> Add Project.

 

אפשרות מס' 3: אף משתמש לא מקושר להתראה הספציפית.

פתרון: במסך של הנקודה בלשונית Alarm Routing -> העבר את כל השמות שבשדה Available roles לשדה "Configured roles for alarm" (לסמן הכל משמאל ולהעביר לשדה הימני).

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

Posted on by אביב צברי

להלן שלבים בהורדת גרסה לבקר CompactLogix

בקרי אלן-ברדלי (Allen-Bradley) הם בקרים מהמובילים בשוק ומן המוערכים ביותר בשוק האוטומציה והבקרה.

1.יש לאתר את סוג ודגם הבקר המדויק באתר:

בחירת דגם בקר אלן ברדלי

2. לבחור את גרסת הקושחה אליה נרצה לעבור:

בחירת גרסת קושחה לבקר אלן ברדלי

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

תצוגת Control-Flash

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

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

6. לאחר שנוצר הפרויקט הזמני ניתן לסגור אותו ולפתוח פרויקט חדש, נוודא ב(HELP) שאכן נפתחה הגרסה שרצינו ונבצע FILE->OPEN לפרויקט הL5K ששמרנו מקודם.

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