Podcast with the CREATOR of MQTT Protocol - Arlen Nipper

Поделиться
HTML-код
  • Опубликовано: 4 июл 2024
  • MQTT Podcast Chapter Summaries
    0:00 - MQTT Sparkplug Protocol: Origins and Evolution
    Exploration of MQTT sparkplug protocol origins, criticism of OPC Foundation leadership, and the necessity of MQTT and AMQP for robust digital infrastructure.
    4:53 - SCADA Systems in the 1980s and 1990s
    Overview of SCADA system technologies involving 300 baud modems and DEC PDP 11, and transition to TCP/IP systems marking a significant protocol shift.
    9:57 - Evolution of SCADA and MQTT Development
    Discussion on SCADA systems' evolution through deregulation, the conceptualization of Pub Sub for industrial systems, and streamlined MQTT development.
    16:49 - Commercialization and Global Use of MQTT
    Introduction of MQTT as a binary protocol for industrial automation, its adoption by Eclipse, and worldwide commercial application demonstrations since 1999.
    22:04 - Development of Sparkplug Protocol
    Creation of Sparkplug A and B to address inefficiencies and challenges of standardization including technical and stakeholder negotiations.
    27:13 - Applications of MQTT and Sparkplug
    Explanation of MQTT as a stateful protocol enhancing reliability, and the expansion of Sparkplug’s applications beyond initial expectations.
    35:28 - Device Connectivity and Real-Time Challenges with Sparkplug
    Analyzing Sparkplug’s strengths and limitations in device connectivity and the challenges it faces in updating data in real-time environments.
    40:46 - Enhancing MQTT with IoT Core and Plugins
    Need for a standardized MQTT plugin system for better device interaction and the complexities of gathering standards bodies for industry-wide consensus.
    46:29 - Standardizing MQTT Query Language
    Proposal for a simple, effective standardized query language for MQTT based on existing commercial products and integration challenges with OPC UA.
    53:30 - Real-Time Data Integration Using MQTT and Sparkplug
    Use of MQTT and Sparkplug for real-time data transfer to cloud services and how simplicity aids in PLC connectivity and data transfer to databases.
    57:48 - Using Snowflake for Unified Data Management
    Discussion on using Snowflake as a robust platform for data management, emphasizing the need for quality of service and schema preservation.
    1:02:29 - QoS Concerns and Data Integrity in SCADA Systems
    Addressing Quality of Service issues and their impact on command reliability and data integrity within SCADA systems using MQTT.
    1:08:08 - IoT Infrastructure and Message Ordering Challenges
    Exploration of IoT infrastructure improvements, TCP vs. UDP debates, and the challenges of ensuring message order in industrial communication systems.
    1:12:18 - MQTT Security and Standard Evolution
    Benefits and challenges of MQTT security model, discussions on upgrading to new Sparkplug versions, and the necessity of native JSON encoding.
    1:18:02 - Improving Sparkplug Messaging Architecture
    Suggestions for enhancing Sparkplug’s structure to support hierarchical device topics and smarter subscriptions for dynamic data filtering.
    1:23:51 - Cloud Computing, Data Management, and Standardization
    Potential of cloud platforms like Snowflake to transform data analysis, and advocacy for dynamic topic assignments similar to DHCP in IoT devices.
    Ready to dive deeper into the world of IIoT and Industry 4.0? 🌐
    Join our thriving community on Discord and engage with like-minded individuals! 💬
    👉 bit.ly/Industry40DIscord
    Supercharge your IIoT knowledge with our FREE Mini-Course! 🚀
    👉 bit.ly/iiotmini-course
    Thank you for your support, and stay tuned for more exciting content! 🙌
    #IIoT #Industry40 #DigitalTransformation
  • НаукаНаука

Комментарии • 26

  • @marc_akoto
    @marc_akoto Месяц назад +1

    Technology embodied by experts focusing on real use-cases and impactful developments, I love that !

  • @mathiaspoulsen84
    @mathiaspoulsen84 2 месяца назад +4

    Great conversation and awesome to see a couple of experts discussing new functionalities that could enhance MQTT Sparkplug.

  • @pugaljanakiraman8590
    @pugaljanakiraman8590 2 месяца назад +2

    big fan of I4.0 solutions and learnt a lot from this channel to set the OT data ingestion strategy for Snowflake and I will always remain a lifelong student of Arlen from AWS days into Snowflake now.

  • @EmileAckbarali
    @EmileAckbarali 2 месяца назад +4

    This was a joy to listen to, extremely interesting. The history of the MQTT described by Arlen was the best part for me, was just absolute gold. This kind of information is rare. Thanks a lot 4.0 Solutions and Walker.

  • @JeffRankinenAmyJoey
    @JeffRankinenAmyJoey 2 месяца назад +4

    Great conversation! My best takeaway is Arlen's vision at 1:26:35 - All equipment should already speak Sparkplug. When a new factory is set up, the machines would automatically start talking Sparkplug upon connection. This would eliminate the need for engineers to spend time connecting protocols to machines. Additionally, it would allow for faster recovery times in case of a system failure.

  • @SolidStateSoul
    @SolidStateSoul 2 месяца назад +1

    The longer videos are always the best. Thanks!

  • @utorrent01
    @utorrent01 2 месяца назад +3

    Very interesting question towards the end for MQTT Wishlist - DHCP like concept for topic names the client can publish to.
    Maybe there’s a good business case to implement a Topic Registration service. I don’t believe any changes needed to MQTT itself as such

  • @SaurabhGuptacurious
    @SaurabhGuptacurious 2 месяца назад +1

    Fantastic conversation.loved every minute with Arlen. It’s rare.

  • @sebastiangonzalez7192
    @sebastiangonzalez7192 2 месяца назад +2

    Hi Walker, Zach and team. Great video with valuable and rare insight. I appreciate having something productive to listen while working.
    PS: I read the description on the video and clicked on the discord server link. A message stating this link is invalid appeared.

  • @ImSuperGoodAtDancing
    @ImSuperGoodAtDancing 2 месяца назад +2

    He’ll yeah Arlen Nipper is the man!!

  • @ravis2381
    @ravis2381 2 месяца назад +2

    Nice one , Good Job Walker !!

  • @xart007
    @xart007 2 месяца назад +2

    Great conversation

  • @rickbullotta8253
    @rickbullotta8253 2 месяца назад +6

    AND not OR™

  • @utorrent01
    @utorrent01 2 месяца назад +2

    Great content 🎉

  • @Lachlan.Wright
    @Lachlan.Wright 2 месяца назад +2

    27:18 What a great question! 😀 Haha! ❤

    • @Lachlan.Wright
      @Lachlan.Wright 2 месяца назад +1

      57:58 Another great question. Gee this Lachlan guy is pretty great.

    • @Lachlan.Wright
      @Lachlan.Wright 2 месяца назад +1

      Loved this one Btw! One of your best postcards!

    • @goldensunalways2228
      @goldensunalways2228 2 месяца назад

      ​@@Lachlan.Wright ????

    • @Lachlan.Wright
      @Lachlan.Wright 2 месяца назад

      @@goldensunalways2228 It's a little bit of an in joke. There was a bit going on publicly between Walker and myself recently. But these two questions were ones I raised in the discord, so it is nice that I am not just recognized as a troll.

    • @ravis2381
      @ravis2381 2 месяца назад

      @@Lachlan.Wright Let me try to put things in my perspective , Its nice to see @Walker treating you so well and ensuring a detailed discussion is being conducted just to ensure you and the community benefits, he could have ignore you royally too...
      in my opinion Walker was always right when he said by default is report by exception which actually IS a subset of *UNSOLICITED* outputs ... sent without being asked to reduce latency in a way due to the basic protocol rules!!!
      Correct me here , OPC DA/UA is poll response to start with and can not take IN *UNSOLICITED* DATA. Under( As SUBSET of) *UNSOLICITED* outputs ONE can implement range BASED or further details like why ( change in value based on band width logic etc) and when to send the data , you can not achieve this if a very high speed Data needs to be transmitted and one can wait for the logic to complete before sending those values , just as an example Microprocessor based Numerical relays are used in Power systems to detect which breaker tripped first and caused the tripping in the other circuit and due to what analogue reasons wherein you can have 100s of breaker tripping at the same time ( human recognizing of time) and you need granularity of millisecond to microsecond of which circuit actually caused the series of breaker to trip almost at the same time !!! Multiple values are send as a bust and then evaluated which microsecond one value misbehaved just for a fraction of a second causing the entire system to shut down..
      Not easy to achieve what walker has been able to achieve building up this committee, at the end of day every one earns some money , you too, and no one stops you to build your own group !! Who knows you may build a better one benefiting the masses and satisfying trolls much better than @Walker does , i enjoy every bit of it even if i sometimes dont like it or laugh at the way he deals with people !! He is like Mike Tyson for me !!! One of the best !!

  • @utorrent01
    @utorrent01 2 месяца назад +3

    I actually disagree with Aron regarding sparkplug implementation and JSON. All well and good to have SB C, SBD etc. but don’t forget what makes MQTT great - simplicity and flexibility for the developer how you want to use it. Guaranteeing the compatibility with any broker is also a key. Please don’t over complicate MQTT. Sparkplug as is, is okay. But more happy with vanilla MQTT.
    Interoperability is the key for successful digital transformation. If there are 10 different types of MQTT, well, there is no one standard anymore.

    • @utorrent01
      @utorrent01 2 месяца назад

      To some extent, I also disagree with Walker here about limitations of MQTT. Once it is over complicated, it will be harder to adopt.

    • @utorrent01
      @utorrent01 2 месяца назад

      Problem with standards is, there are too many of them 😂