I am looking at putting together a communications protocol for an embedded application, but I don't know much about high-level communications such as TCP/IP, etc. I'm more used to dealing with bits and bytes on I²C and SPI, etc.
Someone has suggested that I use a VISA (virtual instrument software architecture) I/O API with SCPI (standard commands for programmable instruments) command syntax. What layer would these sit at on the OSI model? I'm thinking VISA would be application and SCPI presentation?
Someone else has suggested using SSH, again as I'm not sure what layer VISA/SCPI sits at, I don't know how SSH would affect the design.
Since you're basically just using the network to pass data between a hardware API and an application, you're on layer 7(application) of the OSI stack.
Related
I'm completely new to the space and i have a project that i would like to complete, the project is basically: extracting sensor data in the form of MODBUS than sending the data out through CANBUS. i already have a mod-bus input and a can-bus output.
researching into MODBUS has been a bit confusing so sorry if these questions seem a bit stupid.
Is it possible to write code which can convert MODBUS to CANBUS? or will i need external hardware.
additionally, i'm looking to add a microprocessor to my dev board, is there anything in specific i should look for that would help with my modbus and canbus operations? or will any microprocessor work.
thank you
The basics of all data communication is the OSI model. Start there. Then you'll eventually find out that Modbus is an application layer protocol standard and CAN is a physical/data-link layer standard.
Therefore your question doesn't make any sense. You can't convert an application layer into a physical/data-link layer. You can however convert Modbus to some specific application tier protocol for CAN, such as for example CANopen, Device Net or J1939. Or a custom one.
The lowest layers underneath Modbus is UART and most likely RS-485. Possibly RS-232.
You will need a RS-485 or RS-232 transceiver between the Modbus sensor and your MCU. And you will need a CAN transceiver between your MCU and the CAN bus. Additionally, it is very strongly advised to pick a MCU with built-in CAN controller hardware.
Pick a target hardware that suits your project, don't pick some random dev board and then try to duct tape it with misc hardware to suit the project requirements.
However, the hardware is the easy part. Buying and configuring protocol stacks for whatever application protocols you are using is the hard and expensive part.
Also, there are lots of companies making gateways, so why re-invent the wheel. If you need to convert between for example Modbus and CANopen, these are both well-known industry standards. Consider just buying a gateway.
I'm trying to interface a board level USB camera with a STM32 family microcontroller and send the image file to a central computer using CANbus. Just want to know if this is possible/ has been done before and how involved a task it would be.
I worked at a company where we sent live (low-resolution infra-red) video streams over CAN, but towards the end of my time there they shifted towards ethernet.
So it is possible, but certainly not what it is best suited for. The main advantages of CAN are that it is a multi-point, multi-master bus with built in arbitration. It is meant for short packets, typically 8 bytes (CAN FD allows you to increase that).
If your camera is USB, why not just get a USB repeater cable or USB-over-ethernet gateway?
If there is already a CAN network in place that you are piggy-backing onto then you need to consider what impact you will have on the existing traffic.
If you are starting from scratch then of course CAN will work but it would be an odd choice.
Depending on if its CAN or CANFD (Affects the maximum bulk transfer packet size) you have higher level protocol options to packetise your images and send them over canbus like any other block of data.
For just reguarlar CAN your after part of the standard called J1939.21 Data Link Layer, there are public versions of this floating around online, however due to the agreement when purchasing the standard, I am not able to share the specifics from what I have.
Its on pages 27-28 of the 2001 revision.
OSI: Open Systems Interconnection Reference Model
OPC: OLE (Object Linking and Embedding) Process Control
I can‘t figure out the difference, since both of these refer to communication between machines.
Glad about any answer. Thanks
The Open Systems Interconnection (OSI) Model is a logical layout to define how systems should communicate with each other, using various protocols available at each of seven layers. It is a universal language to guide vendors and IT professionals to develop products and solutions or troubleshoot problems in networks. So, it is more like a conceptual tool than a specific protocol specification or a single technology.
On the other hand, OPC (Open Platform Communications, formerly OLE Process Control) can be described as an industrial standard M2M protocol for interoperability. The OPC standard is a series of specifications with a long history. The platform-dependent old specifications are called OPC Classic, and the next generation of OPC technology is known as OPC UA. In other words, it defines a specific communication solution in order to address a certain gap in industry.
Consequently, as a reference model and a generic tool, we can use the OSI model to develop a better understanding of how OPC deals with the problems we have in industrial networks today.
I have been playing around with OpenThead for about a month and I have set up two TI CC2538s in an OpenThread network, currently, I can send pings between them and modify the network parameters using the CLI, but they aren't capable of much else.
I would like to develop an application for them that is capable of transmitting some form of data using the OpenThread stack, maybe something simple at first like transmitting a block of text, however, I am not really sure where to start with this, are there any example applications that I could use as a starting point?
For application layers that sit directly on top of OpenThread, Nordic has released some examples in their nRF5 SDK for Thread.
Also note that Thread (and OpenThread) implement an IPv6 link capable of transporting vanilla IPv6 datagrams. As a result, you could run other transport protocols like TCP. However, UDP is often recommended due to relatively high loss rates and latency variance that is common to low-power, wireless mesh networks.
I am confused between the following terms: OpenFlow, Open vSwitch, and Mininet. I want to understand the relationships between them. Kindly, can someone provide when and how to use each one of them?
Thank you.
Let me explain OpenFlow first. In traditional legacy network devices, the control decisions unit and the forwarding unit are tightly coupled (like switches, routers, etc., where both the control decisions like say, optimal route calculation and the forwarding occur in the same device). The hardware of these devices is made specifically for a particular task. They are not flexible enough to allow researchers to test new algorithms that they might come up with to solve any of the networking issues (say they have a better congestion-control algorithm for TCP!). This requires researchers to create their own custom hardware and have a whole new setup for each experiment.
It would be a lot better if commercial switch providers allowed more flexibility, thus allowing researchers to test their new idea on the same network without new hardware.
As per the white paper on OpenFlow, an OpenFlow switch allows this flexibility and OpenFlow is the protocol used to manage the switch (i.e., add/remove/modify flow entries, capture flow statistics, etc.,). The user program that uses OpenFlow to communicate with the OpenFlow switch is called the controller. There are various frameworks available for writing controller applications. Examples are Ryu are OpenDaylight.
SDN is based on this idea of de-coupling the control and forwarding unit (also called the data plane). Not only is this useful for researchers, but also for data centers, as it reduces the cost of changing hardware each time a change is required.
OpenVSwitch - The 'V' stand for Virtual. This is a "virtual" OpenFlow switch. Apart from OpenFlow, it also supports other switch management protocols.
Many people ask if an OpenFlow switch operates at layer 2 or layer 3. Note that there is no such concept here. In an OpenFlow switch, forwarding decisions can be taken based on MAC, IP, in-port, VLAN_ID, etc., So Please don't try to fit this into the OSI model.
Mininet is a network emulator. The user can create any kind of topology with multiple hosts and switches. The type of the switch could also be chosen.
OpenVSwitch is a software OpenFlow switch that can be controlled by a Controller
OpenFlow is the protocol through which your Controller communicates with its OpenFlow switch
Mininet is an emulator that emulates a network utilizing multiple instances of software switches