Contact Shouab

Online Scheduling or Send a Message

Test Smart Top Management
Get Adobe Flash player

Highlights

نظراً للتكلفة الباهظة الرأسمالية لمكونات المشاريع التي تنفق حتى إكمال المشروع والتي تبلغ في معظم الأحيان ملايين الدولارات. فمن البديهي أن تتم المحافظة على تلك المكونات الباهظة القيمة من جميع المؤثرات التي تؤدي إلى تلفها أو إنقاص عمرها الافتراضي. وتتم المحافظة على هذه المكونات بإجراء الصيانة الصحيحة المخططة والمدروسة لجميع مكونات المنشأة بدون إستثناء. والمشكلة تكمن في بعض الأحيان أن إدارة المنشأة تتجاهل دور الصيانة الصحيحة بجميع أنواعها المختلفة بدافع تقليص المصروفات لزيادة الربح.

إقرأ المزيد

Contact Info

an image

SMART TOP MANAGEMENT
م. خالد شعيب

البريد الالكتروني
info@
Smart-Top-Management.com


التليفون
010 - 0000 9721

Send your order

منظومة إدارة المباني

 

منظومة إدارة المباني:Building Management System - BMS

ويعنى بها كل المهندسين الذين يعملون في مجال خدمة المباني (Building services) من فنادق ومستشفيات ومبانٍ سكنية وإدارية وخاصة ونحو ذلك، أي المتخصصين في المجالات التالية:

تكييف الهواء والتحكم فيه HVAC and Controlأعمال الكهرباء (قوى وإضاءة وتيار خفيف) (Electricity (Power, Lighting, and Low Currentالأعمال الصحية SanitaryWorksشبكات مكافحة الحريق Fire Fighting Networks

يحتاج أصحاب الفنادق والمباني الحكومية الهامة والمستشفيات إلى منظومة لإدارة المبنى، والإدارة هنا تعني شيئين اثنين هما: المراقبة (Monitoring) التحكم (Control) أي أن المنظومة تمكن صاحب المبنى و/ أو مدير التشغيل والصيانة أن يراقب كل معدات وأجهزة المبنى وأن يتحكم فيها مركزياً من خلال حاسب شخصي متصل بكل المعدات عن طريق مستشعرات (sensors) ومتحكمات (controllers)، في شكل شبكة منطقة محلية (Local Area Network - LAN).

الغرض من هذه المنظومة:

المراقبة والتحكم مركزياً في كل الأجهزة المعنية في مبنى أو مجموعة مبانٍ.

محتويات المنظومة:

أولاً : حاسب أو عدة حواسب (حسب طلب العميل) وهذا فيالمستويات العليا للإدارة والتشغيل (Management and operation level)

ثانياً: متحكمات (controllers) وهذا هو مستوى المنظومة (System level) أو مستوى الميكنة (Automation level)

ثالثاً: مستشعرات (sensors) لتشعر بالمتغيرات المرادقياسها - من درجة حرارة ورطوبة وضغط وسريان وتيار وجهد كهربي (فولط) ونحوذلك- ومشغلات (actuators) لفتح وغلق الصمامات المراد التحكم فيها، وهذا هو المستوى الحقلي (Field level) إذن فمستويات المنظومة هي:

1. مستوى الإدارة Management level(المالك أو مدير الصيانة)

2. مستوى التشغيل Operation level(مهندسو وفنيو التشغيل)

3. Automation or System levelمستوى المنظومة

4. Field levelالمستوى الحقلي

وحيث أن المتحكمات في هذه الأيام من النوع الرقمي (digital) ولكل منها مشغل دقيق وقد نطلق عليه معالج دقيق (microprocessor) فنلاحظ أن إشكالية ربط هذه المعالجات الدقيقة هذه ببعضها البعض، هي نفس إشكالية ربط مجموعة حاسبات ببعضها البعض فيما نسميه شبكة منطقة محلية (Local Area Network) فعلى سبيل المثال إذا أحضرنا حاسباً شخصياً إلى أي شبكة حاسبات في مكانٍ ما، هل يمكننا توصيل الحاسب الشخص مباشرة بالشبكة كي نستفيد من الخادم(Server) والطابعة ؟؟؟

الإجابة بالنفي لأن الحاسب الشخص يحتاج إلى بطاقة(كارت) شبكة (Ethernet Card) لكي يتوافق مع الشبكة.

نفس الشيء بالنسبة للمتحكمات، فهي مجهزة للعمل ضمن شبكة منطقة محلية.

السؤال الآن: كيف تنتقل البيانات من معالج إلى معالج آخر عبر الشبكة، سواء أكانت شبكة متحكمات لمنظومة (BMS) أو حاسبات ؟

هنا أصبحنا بصدد ما يسمى " البروتوكول"، فما هو تعريف البروتوكول ؟

البروتوكول: هو مجموعة من القواعد التي تحكم انتقال البيانات عبر الشبكة.

تجدر الإشارة إلى أنه قبل ظهور المعالجات الدقيقة لم تكن هناك حاجة إلى بروتوكول إذ كان لشبكة المنظومة حاسب واحد فقط مركزي يستقبل كل البيانات من حرارة ورطوبة وسريان وتيار ويقرر هو لكل صمام أو مروحة أو مكيف أو محول أن يعمل أو يتوقف جزئياً أو كلياً. أي لم تكن هناك حاجة لربط معالجات.

فكان البروتوكول هو الحل لإشكالية المتحكمات الرقمية. ولكن فكر الإنسان يعتمد تقدمه على المحاولة والخطأ (Try and error)

فكان البروتوكول حلاً يحمل بين طياته إشكالاً آخر – مثل ما حدث في الأسطورة الإغريقية هرقل والعدار (Hydra) التي كان كلما قتل لها رأساً ظهرت لها رأس غيرها - هذا الإشكال هو اقتصار البروتوكول على الشركة المنتجة له وللمتحكمات، ومن ثم عشنا في الثمانينات فترة ظهور المتحكمات الرقمية المباشرة، ولكن بأسلوبٍ احتكاري، فلم يكن ثمة سبيل إلى التوافق بين متحكمات شركة تحكم مع متحكمات شركة تحكم أخرى !!!!

فكانت الثمانينات عقد الاحتكار للمتحكمات

بعد ذلك، خرجت علينا الشركة الأمريكية (Echelon) عام 1990 في ولاية كاليفورنيا وموقعها:

http://www.echelon.com/

بحلٍ جديد لكسر الاحتكار، ويتمثل هذا الحل في بروتوكول أطلقوا عليه اسم (LonWorks)

واتبعته العديد من شركات التحكم بحيث أمكن ربط متحكمات (Controllers) رقمية من أكثر من مصدر ببعضها البعض.

ومن ثمّ أمكن كذلك إحلال متحكمات من شركة ما مكان متحكمات من شركة أخرى تعمل على نفس البروتوكول وذلك في حالة التلف أو عند الرغبة في التحديث أو التوسع ونحو ذلك.. فكان ظهور هذا البروتوكول علامة على الطريق وكان فتحاً كبيراً لشركة إيشلون التي كانت تستخدم بروتوكول (Lon Works)

في تطبيقات الميكنة الصناعية (Industrial Automation) وتباطأ تسويقه لأصحاب المصانع، ثم أعادت نشره في مجال جديد عليها وهو خدمات المباني (Building Services) والذي يقتصر على محطات تكييف الهواء وشبكات الحريق والسباكة وأعمال الكهرباء (قوى + إضاءة + تيار خفيف مثل التلفزيون والكاميرات والهاتف والإنذار والأنظمة الصوتية)

تجدر الإشارة إلى أن المتحكمات المستخدمة في مجال الميكنة الصناعية يطلق عليها " متحكمات منطقية مبرمجة " (Programmable Logic Controller) واختصارها (PLC) وهي تقابل ما نسميه متحكمات رقمية مباشرة (DDC) في مجال خدمات المباني ولكن إلى أي درجة نجح بروتوكول (LonWorks) في فرض الانفتاح فيما بين المنتجين/ المصنعين (manufacturers) وإنهاء الاحتكار؟

فنقول إن البروتوكول سمح بإمكانية التشغيل البيني – أو تبادلية التشغيل – (Interoperability) فيما بين المتحكمات التي تتبناه أي تعمل بمقتضاه،... ولكن... لاننس أن البروتوكول صادر عن شركة!! لها حساباتها في المكسب والخسارة، كأي منشأة تجارية تحقق الربح لأصحابها.....!!! ومن ثم فكان هناك مسمار جحا...!!!

إذ عمدت الشركة إلى تصميم شريحة أسمتها " الشريحة العصبية" (Neuron Chip) بدونها لا يعمل البروتوكول، وأصبحت هذه الشريحة داخل كل متحكم رقمي مباشر (DDC) يعمل وفق بروتوكول (LonWorks) !! فأصبح البروتوكول مشروطاً بوجود هذه الشريحة.

واللافت للنظر أن الذي ينتج الشريحة هو طرف آخر كان في البداية شركة ما، ثمّ أصبحت تنتجهُ شركة توشيبا وشركة تسمى (Cypress) وهذه مشكلة ثانية.

كذلك تجدر الإشارة إلى أن أي شبكة لمنظومة إدارة المباني يجب تحصيل رسوم عليها عن كل قطعة/ لوحة (node) في نظير توصيل الشبكة (Networking) ورسوم أخرى في نظير الهندسة (Engineering) وهذه مشكلة ثالثة.

إذن لم يخلُ هذا الحل من الاعتبارات التجارية!!!

جدير بالذكر أن الجمعية الأمريكية لمهندسي التدفئة والتبريد وتكييف الهواء، والمعروفة بسم

American Society of Heating, Refrigerating, and Air-conditioning Engineers, Inc.

واختصارها (ASHRAE) وموقعها http://www.ashrae.org/جمعية علمية لاتسع لتحقيق ربح (Non-profitOrganization)، وقد طلب إليها في الثمانينات المعـنيون بمعضلة الاحتكار في سوق المتحكمات الرقمية ومعضلة الافتقار إلى إمكانية التشغيل البيني (Interoperability) بين المتحكمات المختلفة المصدر أو بين المتحكمات ومعالجات (processors) المبردات (Chillers) والمصاعد وأنظمة إنذار الحريق وبقية منظومات المبنى.

فعكفت الجمعية على دراسة وإصدار بروتوكول جديد مفتوح، وكونت لجنة عام 1987 أسمتها اللجنة الدائمة لمشروع المقياس

Standing Standard Project Committee – SSPC

وأعطتها الرقم 135 فصار اختصارها SSPC 135

بقيادة السيد مايكل نيومانMichael Newman، مدير قسم الحاسبات بمرافق جامعة كورنيل بولاية نيويورك، ونائبه (Steven Bushby) في المعهد القومي للمقاييس والتقنية (NIST) حتى تمكنوا بفضل الله من إصدار البروتوكول بعد ثمان سنوات أي في عام 1995، فأطلقوا عليه "باكنت" (BACnet) وهو اختصار للتالي: Building Automation and ControlNetwork

ويعني : شبكة ميكنة المباني والتحكم فيها

ومن الجميل أن كلاً من المعهد الأمريكي الوطني للتوحيد القياسي (ANSI) وجمعية (ASHRAE) قد تبنيا البروتوكول ضمن المقاييس (standards) الصادرة عنهما وأعطياه رقم 135فأصبح مقياساً لهما برقم:

ANSI/ASHRAE Standard 135 / 1995

وموقعه: http://www.bacnet.org/

البروتوكولات التسعة المستخدمة في السوق لمجال خدمات المباني سواء أكانت لمبانٍ (فنادق ومستشفيات ومطارات... ونحو ذلك) أو لمجرد سكن منزلي وشقق هي

BatiBUS

CAB – Canadian Automated Building protocol

CEN – European Committee for Standardization

EHS – European Home Systems

EIB – European installation Bus

FND – Firm Neutral Data Communication

PROFIBUS – Process Field Bus

World (FIP) Factory Instrumentation Protocol

LonWorks

OSI Basic ReferenceModel

مع تحيات م: خالد شعيب

يمكنك إرسال طلبك أو إستفسارك مباشرة من خلال هذا الرابط
Contact us : 0100 - 0000 9721
Send Your Order Now