چرا سوال «آیا BMS شما میتواند از CAN پشتیبانی کند؟» سوال اشتباهی در تدارکات است؟
بیشتر برگههای اطلاعات فنی سیستمهای مدیریت ساختمان هوشمند (Smart BMS) پروتکلهای ارتباطی را به عنوان یک چک لیست ویژگیها فهرست میکنند: CAN، RS485، UART، بلوتوث، و گاهی موارد دیگر. این موضوع اطمینانبخش است - هر چه موارد بیشتری ذکر شده باشد، بهتر است. اما این لیست به سوال مربوط به تدارکات پاسخ نمیدهد.
دو واحد BMS میتوانند هم از CAN پشتیبانی کنند و هم با یک اینورتر یکسان ناسازگار باقی بمانند، زیرا ساختار پیام آنها متفاوت است. همین امر در مورد نمایشگرهای NMEA 2000، داشبوردهای RV-C و پلتفرمهای EMS (سیستم مدیریت انرژی) نیز صدق میکند. پشتیبانی در سطح پروتکل نقطه شروع است، نه نتیجه.
این مقاله به بررسی این چارچوب میپردازد: هر پروتکل چه کاری انجام میدهد، هر کدام در کجا قرار میگیرد، و چگونه میتوان ارتباطات را در مرحله RFQ (درخواست پیشفاکتور) مشخص کرد تا «پشتیبانیها» به «سازگار» تبدیل شوند - تفاوت بین پروژهای که به طور کامل ادغام میشود و پروژهای که با شکاف راهاندازی مواجه میشود.
کاری که این چهار پروتکل واقعاً در یک بسته باتری انجام میدهند
صرف نظر از موارد ضروری تهیه، در اینجا کاری که هر پروتکل در واقع در یک بسته باتری انجام میدهد، آورده شده است:
| پروتکل | لایه ارتباطی | نقش معمول | جایی که زندگی میکند |
|---|---|---|---|
| میتوان | گذرگاه شبکه (چند دستگاهی) | یکپارچهسازی بلادرنگ خودرو و سیستمهای صنعتی | کنترلکنندههای خودرو، ماشینآلات صنعتی، شبکههای سیستم (RV-C، NMEA 2000 و J1939 که بر اساس CAN ساخته شدهاند) |
| RS485 | گذرگاه سریال (چند دستگاه، مسافت طولانیتر) | نظارت میزبان، مدیریت ناوگان، اسکادا | سیستمهای مدیریت ناوگان، ایستگاههای نظارتی، لایههای نظارتی صنعتی |
| یوآرتی | سریال نقطه به نقطه | سیمکشی سختافزاری زیربنایی | زیر برخی از لینکهای سریال (مثلاً فرستنده-گیرندههای RS485، ماژولهای بیسیم) قرار میگیرد؛ یک قابلیت سختافزاری است نه یک انتخاب کاربری |
| بلوتوث | بیسیم برد کوتاه | تشخیص و پیکربندی مبتنی بر برنامه | اپلیکیشنهای موبایل مالک یا نصاب برای نظارت بر تک تک بستهها |
پروتکلها قابل تعویض نیستند. CAN یکپارچهسازی بلادرنگ را مدیریت میکند، RS485 مانیتورینگ را مدیریت میکند، UART لایه سیمکشی سختافزار است و بلوتوث با مالک در ارتباط است. پروتکل مناسب بستگی به این دارد که دستگاه پاییندستی - اینورتر، داشبورد، سیستم ناوگان، برنامه تلفن همراه - چه اطلاعاتی را باید بخواند.
سوال این نیست که آیا یک BMS از CAN پشتیبانی میکند یا خیر. سوال این است که آیا با گویشی که اینورتر، کنترلر، نمایشگر یا شبکه شما انتظار دارد صحبت میکند یا خیر.
CAN: موتور محرکه ادغام خودرو و صنعت
CAN لایه پروتکلی است که بیشتر ادغام سیستم خودرو و سیستم صنعتی در آن اتفاق میافتد. وقتی یک کنترلکننده لیفتراک وضعیت شارژ باتری را به صورت بلادرنگ میخواند، وقتی یک شبکه شاسی RV باتری و شارژر را هماهنگ میکند، وقتی یک نمایشگر دریایی وضعیت موتور و باتری را میخواند، پروتکل اساسی تقریباً همیشه CAN است.
«پشتیبانی از CAN» به تنهایی اطلاعات کمی در مورد اینکه آیا یک BMS خاص با یک دستگاه خاص ادغام میشود یا خیر، ارائه میدهد. حوزههای مختلف، استانداردهایی را بر اساس CAN ساختهاند - RV-C، NMEA 2000 و J1939 - که هر کدام ساختار پیام خاص خود را دارند. دو واحد BMS که از CAN پشتیبانی میکنند، میتوانند پیادهسازی پیام کاملاً متفاوتی داشته باشند و با یک دستگاه یکسان ناسازگار باقی بمانند.
برای یکپارچهسازی مبتنی بر CAN، سوال RFQ درست این نیست که آیا BMS از CAN پشتیبانی میکند یا خیر، بلکه این است که چه پیادهسازی پیامی را ارائه میدهد و تأمینکننده چه سازگاری برای دستگاههای خاص شما ارائه میدهد.
RS485: استاندارد نظارت بر میزبان و ارتباطات از راه دور
RS485 لایه متفاوتی را اشغال میکند. در حالی که CAN در هماهنگی بلادرنگ برتری دارد، RS485 کابلهای طولانیتر و لایه نظارت بالاتر از کنترل عملیاتی را مدیریت میکند - مدیریت ناوگان که بسیاری از بستهها را ردیابی میکند، پلتفرمهای SCADA (کنترل نظارتی و جمعآوری دادهها) و ایستگاههای نظارت میزبان.
یک الگوی صنعتی معمول، CAN برای یکپارچهسازی بلادرنگ به همراه RS485 برای لایه نظارت است. کنترلکننده لیفتراک از طریق CAN با BMS ارتباط برقرار میکند؛ مدیریت ناوگان سلامت بستهها را از طریق RS485 میخواند. این دو رقیب یکدیگر نیستند - آنها به لایههای معماری متفاوتی خدمات ارائه میدهند.
برای RS485، به جای اینکه عبارت «پشتیبانی از RS485» را به عنوان تضمین سازگاری در نظر بگیرید، تأیید کنید که پیادهسازی BMS با پلتفرم نظارتی خاص شما مطابقت دارد.
UART: لایه سختافزار (کمتر درباره انتخاب، بیشتر درباره بنیان)
UART یک لینک سریال نقطه به نقطه است که در زیر برخی از اتصالات سطح بالاتر قرار میگیرد - برای مثال، UART یک میکروکنترلر اغلب یک فرستنده-گیرنده RS485 را هدایت میکند و ماژولهای بیسیم معمولاً از طریق UART به میزبان متصل میشوند. با این حال، CAN بر اساس این ساخته نشده است: CAN از کنترلر و فرستنده-گیرنده خود استفاده میکند. برخی از سنسورها و ماژولها مستقیماً از طریق UART و بدون یک لایه پروتکل اضافی متصل میشوند. در برگههای اطلاعات Smart BMS، UART معمولاً به عنوان یک قابلیت سختافزاری به جای یک پروتکل کاربرپسند مانند CAN یا RS485 ظاهر میشود.
برخی از پلتفرمهای BMS صنعتی، کانالهای UART متعددی را برای تشخیص، پیکربندی یا ادغام لوازم جانبی ارائه میدهند - که بیش از انتخاب پروتکل، بر برنامهریزی سختافزار تأثیر میگذارند.
برای تدارکات: یک BMS که فقط UART (بدون پروتکل سطح بالاتر) را فهرست میکند، برای سیمکشی مستقیم دستگاه طراحی شده است، نه ادغام شبکه. وقتی تجهیزات پاییندستی - اینورتر، کنترلر، نمایشگر، مدیریت ناوگان - انتظار ارتباط CAN یا RS485 را دارند، فقط UART ممکن است کافی نباشد. بررسی کنید که طرح ادغام شما چه چیزی را نیاز دارد.
بلوتوث: وقتی نظارت مبتنی بر برنامه واقعاً اهمیت دارد
بلوتوث در لایهی متفاوتی عمل میکند. در حالی که CAN و RS485 سیستم مدیریت ساختمان (BMS) را به سایر دستگاههای سیستم متصل میکنند، بلوتوث معمولاً BMS را به یک اپلیکیشن موبایل کاربر نهایی یا نصاب متصل میکند - نظارت بر وضعیت شارژ، پیکربندی و تشخیص خطا روی بستههای جداگانه.
بلوتوث در مواردی که تعامل مستقیم کاربر یا نصاب با بستهبندی بخشی از موارد استفاده باشد، بیشترین کاربرد را دارد: ارتقاء لیتیوم پس از فروش، راهاندازی نصاب، محصولات کانال خردهفروشی. برای تولید بستهبندی بستهبندیشده OEM که نظارت از طریق شبکه سیستم انجام میشود، بلوتوث اغلب هزینه را بدون ارزش اضافه میکند.
سوال مربوط به تدارکات این است که آیا مدل توزیع و خدمات شما، گروه را در معرض تعامل مستقیم مبتنی بر برنامه قرار میدهد یا خیر. اگر نه، بلوتوث یکی از ویژگیهایی است که به راحتی میتوان آن را مشخص کرد.
چارچوب تصمیمگیری بین سناریوها: کدام پروتکل برای کدام کاربرد
سناریوهای مختلف کاربرد، الزامات پروتکل متفاوتی را ایجاد میکنند. بررسی سناریوهای اصلی DALY از پیچیدهترین تا سادهترین سناریوها از نظر پیچیدگی ادغام:
لیفتراک و وسایل نقلیه صنعتی
CAN معمولاً برای یکپارچهسازی کنترلکننده خودرو ضروری است؛ RS485 استاندارد است، جایی که میزبان مدیریت ناوگان، سلامت بستههای ردیابی را کنترل میکند؛ بلوتوث معمولاً برای تشخیص فردی استفاده میشود. برای راهنمایی عمیقتر، به مقاله انتخاب BMS لیفتراک ما مراجعه کنید.
وسایل نقلیه تفریحی (RV-C)
RV-C استاندارد مبتنی بر CAN برای شبکههای RV است. BMS از طریق این گذرگاه مشترک با کنترلکنندههای داشبورد، شارژر، اینورتر و شاسی ارتباط برقرار میکند. تطبیق PGN (شماره گروه پارامتر) مختص پروژه به اندازه پشتیبانی RV-C اهمیت دارد. برای راهنمایی عمیقتر، به مقاله انتخاب RV BMS ما مراجعه کنید.
دریایی (NMEA 2000)
NMEA 2000 یک گذرگاه دریایی مبتنی بر CAN است که باتری، شارژر، نمایشگرها و شبکههای موتور را به هم متصل میکند. هر دو نقش روشن کردن موتور و انباره خانه در یک شبکه واحد ادغام میشوند و برای نمایشگرهای دریایی خاص، در سطح پروژه تطبیق مییابند. برای راهنمایی عمیقتر، به مقاله انتخاب BMS دریایی ما مراجعه کنید.
سیستمهای ذخیره انرژی
CAN ارتباط بلادرنگ BMS با اینورتر را مدیریت میکند؛ RS485 یکپارچهسازی EMS یا SCADA را مدیریت میکند. سازگاری پروتکل اینورتر معمولاً عامل تعیینکننده است. برای راهنمایی عمیقتر در مورد ESS، به مقاله ارتباط BMS ما برای ذخیرهسازی خورشیدی مراجعه کنید.
موتورسیکلت و وسیله نقلیه سبک برقی
استفاده از فقط بلوتوث برای بستههای لیتیوم خردهفروشی و پس از فروش که در آنها نظارت مستقیم از طریق اپلیکیشن مورد استفاده قرار میگیرد، رایج است. تولید بستههای بستهبندیشده OEM برای ناوگان وسایل نقلیه دوچرخ ممکن است CAN را برای ادغام خودرو اضافه کند. الزامات پروتکل با عمق ادغام سیستم افزایش مییابد.
اقتصاد مشخصات: کجا سرمایهگذاری کنیم، کجا بیش از حد مشخصات را تعیین نکنیم
انتخاب پروتکل، مسائل اقتصادی خاص خود را دارد. اگر تعداد پروتکلها خیلی کم باشد، BMS یکپارچه نمیشود؛ اگر تعداد پروتکلها خیلی زیاد باشد، هزینه اضافی برای قابلیتهای بلااستفاده پرداخت میشود.
کجا سرمایهگذاری کنیم:
- تطبیق سطح پروتکل برای دستگاههای خاص پاییندستی در پروژه شما— پشتیبانی از پروتکل عمومی نیست.
- پیادهسازی CAN که با کنترلر، اینورتر یا شبکه سیستم مطابقت داردپروژه شما در واقع از آن استفاده میکند.
- تأیید مرحله پروژه مبنی بر اینکه BMS به گویش پیامی که دستگاههای شما انتظار دارند صحبت میکند، قبل از راه اندازی.
کجا نباید بیش از حد مشخصات را مشخص کرد:
- پروتکلهایی که دستگاههای پاییندستی شما به آنها متصل نمیشوند— پرداخت هزینه برای CAN، RS485 و بلوتوث در حالی که فقط یکی از آنها استفاده میشود، پرداخت هزینه بدون فایده است.
- بلوتوث در تولید بستهبندیشدهی OEMجایی که بسته در معرض برنامههای تلفن همراه کاربر نهایی یا نصبکننده قرار نمیگیرد.
- عمق پروتکل فراتر از آنچه معماری واقعی سیستم نیاز دارد— ادعاهای کلی «پشتیبانی از همه پروتکلها» اغلب نشاندهندهی یک موضع بازاریابی است، نه عمق یکپارچهسازی تأیید شده.
پاسخ درست، تطبیق مشخصات پروتکل با طرح یکپارچهسازی واقعی شماست. تأمینکنندهای که در زمینه تطبیق در سطح دستگاه با شما همکاری میکند، همان کسی است که باید با او همکاری کنید.
رویکرد تطبیق محدوده و پروتکل BMS هوشمند DALY
خطوط DALY Smart BMS ترکیبات پروتکل مورد نیاز سناریوهای کاربردی اصلی را پوشش میدهند:
| خط تولید | پروتکلهای موجود | رویکرد انطباق |
|---|---|---|
| سیستم مدیریت ساختمان هوشمند (BMS) | CAN، RS485، UART، بلوتوث | بسته پروتکل استاندارد هوشمند BMS؛ سفارشیسازی در سطح پروژه برای دستگاههای خاص پاییندستی |
| سیستم مدیریت تعادل فعال (BMS) | CAN، RS485، UART، بلوتوث | بسته پروتکل استاندارد یکسان؛ سفارشیسازی در سطح پروژه برای دستگاههای خاص پاییندستی |
| ذخیرهسازی خانگی BMS | CAN، RS485، UART، بلوتوث | تطبیق پروتکل اینورتر و EMS بر اساس پروژه موجود است |
| BMS جریان بالا | CAN، RS485، UART × 3 | سه کانال UART برای تشخیص، پیکربندی و ادغام لوازم جانبی؛ تطبیق CAN برای هر پروژه |
| سیستم مدیریت باتری خودروهای سبک (RV) | CAN، RS485، UART، بلوتوث | پشتیبانی از RV-C، با قابلیت سفارشیسازی PGN مختص پروژه |
دریایی (NMEA 2000):هر دو نقش روشن کردن موتور و نگهداری خانه توسط خطوط Smart BMS و Active Balancing BMS ارائه میشوند و پشتیبانی از NMEA 2000 از طریق سفارشیسازی پروتکل در سطح پروژه ارائه میشود.
DALY پشتیبانی پروتکل و تطبیق پروتکل را به عنوان مباحث جداگانه در نظر میگیرد: برگه اطلاعات، مواردی را که هر BMS پشتیبانی میکند، فهرست میکند؛ سطح مهندسی پروژه، تطبیق ساختار پیام را برای دستگاههای خاصی که سیستم شما به آنها متصل میشود، مدیریت میکند.
برای پروژههای OEM و یکپارچهساز، به جای تکیه بر ادعاهای کلی برگه اطلاعات فنی، دستگاههای پاییندستی خاصی را که نیاز به خواندن اطلاعات باتری دارند، در طول بحث مهندسی قبل از RFQ به اشتراک بگذارید.
→ مجموعه DALY Smart BMS که بسته پروتکل استاندارد را پوشش میدهد:https://www.dalybms.com/smart-bms/
→ محدوده BMS جریان بالای DALY برای کاربردهای خودروهای صنعتی:https://www.dalybms.com/high-current-bms-products/
سوالات متداول
Q1اگر در برگه اطلاعات سیستم مدیریت ساختمان (BMS) به CAN، RS485، UART و بلوتوث اشاره شده باشد، آیا پروژه من به هر چهار مورد نیاز دارد؟
خیر. برگه اطلاعات فنی، مواردی را که BMS پشتیبانی میکند، فهرست میکند؛ الزامات پروژه تعیین میکند که کدام یک واقعاً استفاده میشوند. خرید پروتکلهایی که به آنها متصل نمیشوید، هزینه را افزایش میدهد. عکس این قضیه خطرناکتر است - نبود پروتکلهایی که دستگاههای پاییندستی شما انتظار دارند، در زمان راهاندازی، شکافهای یکپارچهسازی ایجاد میکند. بر اساس دستگاههایی که BMS باید با آنها ارتباط برقرار کند، مشخص کنید.
Q2تفاوت بین «پشتیبانی از CAN» و «سازگار با اینورتر من» چیست؟
پشتیبانی از CAN به این معنی است که BMS با لایه پروتکل CAN صحبت میکند. سازگاری با اینورتر خاص شما مستلزم ساختار پیام (PGN، شناسه پیام، طرح داده) مورد انتظار اینورتر شماست. دو واحد BMS که از CAN پشتیبانی میکنند، در صورت متفاوت بودن پیادهسازی پیام، میتوانند با یک اینورتر ناسازگار باقی بمانند. سازگاری سطح پیام را در مرحله پروژه تأیید کنید، نه فقط پشتیبانی پروتکل را.
Q3آیا به بلوتوث در یک باتری تجاری OEM نیاز دارم؟
بستگی به این دارد که آیا انتظار میرود کاربر نهایی یا نصاب مستقیماً با بستهبندی تعامل داشته باشند یا خیر. برای تولید بستهبندیهای بستهبندیشده توسط تولیدکنندگان اصلی تجهیزات (OEM) که نظارت از طریق شبکه سیستم انجام میشود، بلوتوث اغلب ارزش افزودهای ایجاد نمیکند. برای بستهبندیهای پس از فروش، خردهفروشی یا بستهبندیهای قابل سرویس توسط نصاب، بلوتوث اغلب توجیهپذیرتر است.
Q4چرا UART در کنار CAN و RS485 ذکر شده است اگر بیشتر یک پایه سختافزاری است؟
UART لایه سیمکشی سریال زیربنایی است که برخی از سنسورها و ماژولها برای انتقال داده از آن استفاده میکنند. در انتخاب، این گزینه کمتر از CAN یا RS485 است - اما تعداد کانالها برای برنامهریزی سختافزار اهمیت دارد. یک BMS فقط UART ممکن است زمانی که تجهیزات پاییندستی انتظار CAN یا RS485 را دارند، کافی نباشد. بررسی کنید که طرح یکپارچهسازی شما چه چیزی را نیاز دارد.
Q5چگونه میتوانم الزامات ارتباطی را در مرحله RFQ مشخص کنم؟
دستگاههای پاییندستی که نیاز به خواندن اطلاعات باتری دارند - اینورتر، کنترلر، نمایشگر، مدیریت ناوگان، EMS، اپلیکیشن موبایل - و پروتکل مورد نیاز هر کدام را فهرست کنید. از تأمینکننده بخواهید که سازگاری در سطح پیام را برای هر دستگاه تأیید کند، نه فقط پشتیبانی از پروتکل عمومی. این کار مکالمه را از «آیا از CAN پشتیبانی میکنید» به «آیا میتوانید پیادهسازی CAN خود را با اینورتر و کنترلر خاص من تطبیق دهید» تغییر میدهد.
درباره دالی
شرکت DALY سیستمهای مدیریت باتری لیتیومی را برای تولیدکنندگان اصلی تجهیزات (OEM)، تولیدکنندگان بستهبندی و یکپارچهسازان در بیش از ۱۳۰ کشور جهان طراحی و تولید میکند و انواع Smart BMS آن از CAN، RS485، UART و بلوتوث در خانوادههای موبایل، صنعتی و ذخیرهسازی انرژی پشتیبانی میکند. DALY که در سال ۲۰۱۵ تأسیس شد، تحت سیستمهای ISO 9001 / ISO 14001 با انطباق با CE و RoHS فعالیت میکند. خط تولید ذخیرهسازی انرژی دارای وضعیت UL Recognized Component (گواهینامه کامل سیستم UL نیست) است. گزارشهای آزمایش و اسناد فنی بنا به درخواست در دسترس هستند، بنابراین مشتریانی که به دنبال صدور گواهینامه محصول خود هستند، مواد پشتیبانی مورد نیاز خود را در اختیار دارند.
تعیین ارتباطات BMS برای پروژه شما؟
اگر در مرحله پیکربندی یک پروژه باتری هستید، تیم مهندسی DALY به جای یک چک لیست پروتکل عمومی، از طریق فهرست دستگاهها، الزامات پروتکل و تطبیق در سطح پیام شما کار میکند.
- نوع پروژه خود، دستگاههای پاییندستی که نیاز به خواندن اطلاعات باتری دارند، مدلهای خاص اینورتر/کنترلر/نمایشگر و الزامات پلتفرم مانیتورینگ را به اشتراک بگذارید.
- لیست دستگاههای خود را به ما بگویید تا پیکربندی مناسب Smart BMS و رویکرد تطبیق پروتکل را به شما پیشنهاد دهیم.
- ایمیل: dalybms@dalyelec.com
صفحه محصول هوشمند BMS:https://www.dalybms.com/smart-bms/
زمان ارسال: ۱۰ ژوئیه ۲۰۲۶