In SysML, when modeling a message, I'm having trouble understanding what element type should be used to define it, its elements, and a port that it flows through.
I'm assuming it is either:
a raw Block
the more specialized InterfaceBlock
Both can type a proxy port (formerly flow port, if I understand correctly), or type most other properties in other blocks as one builds up a full message interface or port system (either straight ports or nested ports). If the base message definition is a normal block, then when do you create a flow property that gets typed by that block, so that something can actually flow from one task to another through the port?
An Interface Block should occur somewhere in there, in order to type the port, right? Does that mean I use it to define a message directly, or does that depend on my port scheme (i.e. whether I nest ports and to what level)?
I guess this boils down to confusion over when you are defining a thing (i.e. a class/block) and when you are defining that this thing is a quantity that flows in your model (a flow of some kind - the message passes from one task or piece of hardware to another).
P.S. I'm using MagicDraw as the SysML tool, but I don't think that should impact the core answer.
The answer, as developed by my team:
Use a full port for the raw network interface, the physical layer.
Use a block to type the network interface, including:
Flow properties that represent physical items flowing out of the port, such as total electrical current (power).
Nested full port elements for physical nested ports, such as pins that make up a physical ethernet port. Type with another block.
Nested <> elements for logical/abstract data flows across the network interface, such as sockets/connections
Use an Interface Block to type each logical connection (nested proxy port) with an Interface Block containing the following:
Flow properties that represent blocks of data, such as messages, which are sent as a group across the connection
Value properties that define characteristics of that connection, such as source and destination IP addresses and port numbers, comm loss and retry info, etc. Note some of this may be better served as meta data in tags as part of a separate stereotype.
Type the data flow properties of the connections with a ValueType whose attributes are the individual data elements of that data block (i.e. the message elements).
Create a new stereotype with a custom name something like "Data Element" and add tags for any meta-data that is needed about each data element, such as length (in bits or bytes), underlying type in the message, any unit or scaling factors, position in the message, etc.
You can even create a generic table at this point which will list every data element in a given message, or in all messages, and add all the relevant Data Element tags as columns, and use it as a current specification for each message and data element of each message, and allow much easier editing of all the information directly in that table.
Why use ValueTypes for data blocks that flow across Proxy Ports? Because then they will show up as Information Flow items instead of Item Flow items across a connector between two Proxy Ports on an Internal Block Diagram (IBD). I.e. when I send a physical item, typed by a Block, it is sent as an Item Flow, but when I send a logical item, such as data, it is typed by a ValueType, and sent as an Information Flow.
This is a starting point - we found issues with nesting the valuetype definitions initially, so opted for a much flatter message definition that contained all the aspects of a message in a single ValueType, rather than nesting them. I'm sure there are ways around this, but how complicated do you want to get?
Related
I've searched for a good explanation for the difference between these two,
but didn't really find one.
What I know till now is that:
correlation id is a string (Guid which was converted to string), and delivery tag is an int.
correlation id is unique for each message, and delivery tag is unique only in
the channel (The channel is the scope).
That's fine....but what is the difference in the purposes? why do we need two identifiers for a message?
The two identifiers exist at two different conceptual layers of communication, and have different properties that are useful in each case. While a protocol could probably be designed that had one identifier serving both purposes, keeping them separate makes both implementations simpler.
Delivery tags
Part of the AMQP communication layer, built into RabbitMQ itself.
Example use: a consumer process can acknowledge that a message has been processed and can be permanently discarded on the broker (RabbitMQ server).
Automatically assigned within the open channel for every message delivered.
Must be unique within that channel in order for the protocol to function correctly. Does not need to be unique across different channels, so a simple incrementing integer is simple to implement.
The same message may be delivered at different times with different delivery tags, or even exist on multiple queues and be delivered simultaneously to different consumers.
Correlation IDs
Part of the logic of the application that is using RabbitMQ, not the broker itself.
Example use: using a matching correlation ID and "reply to" on two separate messages, which the application wants to treat as a request and a response in an RPC pattern.
Needs to be manually added when the message is first created, and is optional.
Not guaranteed to be unique by the protocol, which just sees it as an arbitrary string. It is up to an application to generate in a way that is sufficiently unlikely to collide for its use case, such as an appropriate form of UUID.
Will stay the same every time a message is delivered, no matter how many times it is forwarded or duplicated into multiple queues.
Correlation ID is generally used in the context of RabbitMQ when I want to see a synchronous behavior in which a message is sent and in response to it another sender will send a response but will have the correlationID in the reply-to tag . The common pattern which is replicated in RabbitMQ is the RPC call which is more like a Synchronous messaging.
Delivery Tag is however an indicator of the delivery of the message per channel and generally comes in scope when Acknowledged Delivery model is being followed.
Both have completely different purpose and are not message identifier as such.
I tested and understood SDO rx and tx with the LPC11Cxx demo. But this demo stack has only SDO functions and a driver API. I want to implement PDO for the same. What would be some sample code or implementation steps or functions?
I want to send 68 (ADC data) bytes of data from a slave node to the master node at regular intervals. How can I do that?
For the above task, is SDO better than PDO? How many PDOs do I need to send 64 bytes of data? How can I set PDO mapping and parameters? What is the difference between a master node and a slave node? How do I differentiate from code?
I'm not sure of your example, but if you can send an SDO over the CAN bus, the you should be able to use the PDO, albeit more complicated.
The general steps are:
1. Define your PDO. You are creating a mapping between a PDO and one or more data objects in your node. For example, on my system, I created a Transmit PDO that sets the motor position and velocity (two objects) that responds with another PDO (a receive PDO) that contains motor current, position and status. This is the definition of the PDO.
To use your PDO, send out a PDO message with the COBid you defined in step 1. Fore me, I send PDO 0x201 with the position and velocity. The node will receive this and set the values you give to the object mapping you define. Note the node does NOT act on the data yet.
After you've sent as many PDO's you need (for example, I send PDO for position/velocity to 7 nodes on a bus to control 7 motors), you then send a SYNC. This causes the nodes to act on the PDO data you've sent - ie move the motors.
Each node will respond with a transmit PDO to send back whatever you define. My nodes send position, status, and current.
Repeat as needed.
Google "CANOpen momento dupin" for some example in the document. You'll have to read the doc on your nodes to understand how they are defined, or the chapter in the embedded canopen book. I have some old code you can look at the was provided to me from a vendor. That might be a good source as well. Nodes don't have to support PDO mapping but I think most do.
I have a general question concerning serial port communication and storage of the data. When communicating with a serial port (strictly reading from the port in this case) how would one go about storing and manipulating the data in vb.net? For my project I'm doing, I need to take strings from the serial port and then pull numbers from those strings and sort them (numerically, i.e. highest number found at the top and lowest number at the bottom) For some reason in my code I get inner exception errors when I try to move the data from strings to string arrays but I'm determined to figure it out.
As a general question in terms of vb.net programming in relation to serial port communication, is it intelligent to use backgroundworkers? For example, could/should I use a backgroundworker to handle reading from a serial port and then do arithmetic on my data outside of the backgroundworker?
I'm basically just trying to store my data from my serial port into an array, but I don't know how big the array will be that holds the data (i.e. I don't know how many times I'll have data sent to my serial port)
Any tips/info would be appreciated! Thanks
As a general rule if there is going to be any long running task, you should run it in a seperate thread. You do this so that the user experiance is not affected and the GUI stays responsive.
In the case of serial communications there is usually a poll respond architecture which requires constant event handling.
In my experiance I have had great success handling the Interaction with the serial port in a seperate thread that bubbles up events to the GUI. This way I can then process the data to be displayed or stored in another seperate thread and keep the polling running in almost real time.
When I was consuming registers I would store them many different ways but from what you describe, it sounds like the data you are consuming would be best stored in a List(of String).
This structure can be added to almost infinitly and throught the use of predicates can be sorted. The List structure in .net also has a method to convert itself to an array if necessary.
So here is how I can imagine your interaction:
The GUI thread is started and you initate a connection to your device.
You then set up a thread that will be receiveing the incoming communications from the device
In this thread when data is captured it triggers an event in the GUI.
In the GUI event handler the data is stored in a list and if manipulations need to be preformed on it, they are done in another processing thread that will have a call back handler.
In the call back you can then display or push the data to its final destination.
The key points are that if you are using a GUI you should absolutly have the communication in a seperate thread to maintian stability of the GUI and create a good user experiance.
hi guys i'm making a client-server software and this is my first question
i'd like to ask: how to distinguish data that sended by tcp Connection?
Well, my points are:
-we can determine data that sended by tcpconnection.
for example, we have 3 Listviews in our form
the point of the first listview is for Biodata of client.
the point of second listview is for *The value obtained from the clients
n the point of third listview is for The picture obtained from the clients
in this case we have 3 main points that must be processed.
in fact, we only have 1 connection in our system.
Well, here I'm confused..
how to determine that data we received is for the first listview or second listview or third listview?
remember, the data of third listview is a picture that we received from tcpconnection
How do we do that with 1 connection in our system?
do i have to make 3 connection to control third listviews?
With socket communication, both the client and the server must use the same agreed-upon protocol so that they can understand each other. There are many standard protocols that have already been created, so for most tasks, creating your own protocol is unnecessary. However, if you must, you can always define your own protocol. The nature of your protocol will obviously depend completely on your specific needs, so it would be impossible to tell you what the protocol should be. However, generally speaking, the first thing your protocol must define is how to know where each complete message begins and ends. This is often accomplished by separating each message with a delimiter (e.g. new line, EOF, null). As Francois recommended, you could alternatively specify the length of the message at the beginning of each message. Within each message, you then will need a header section which, among other things, would specify the type (the format) of the data stored in the body of the message.
A simple implementation might be to send each message as a JSON or XML document. Doing so makes it very easy to define and modify the format of the message.
However, unless you really need to, I would recommend using one of the built-in communication frameworks that are provided with .NET. For simple tasks, often a simple asmx web service is sufficient. For more complex tasks, often WCF is a good choice. An asmx web service uses SOAP via HTTP via TCP/IP. WCF uses SOAP, but the lower level connection is configurable so it doesn't have to use TCP/IP, but it can easily do so.
This Question is extension of the following
OpenFlow Rule Metadata
I would like to have this clarified, on my question about Metadata
Let us say, I have an Open Flow rules, as below
Cookie=0x8000001, duration=228925.445s, table=17, n_packets=350, n_bytes=32424, priority=10,metadata=0xc000f30000000000/0xffffff0000000000 actions=goto_table:19
I wanted to understand the following
Do we have certain rule/ Algorithm , to determine these Metadata from a Packet.
because the Packet in OVS is actually switched based on Matching Metadata, Is that correct ?? ( At least according to the above flow rule )
And the Packet itself does not carry the Metadata, then how exactly
the packet hitting a flow matched against the Metadata.
So, If I understood it correctly the Packets those are traversed between the flow-tables, are within the OVS application itself or Handled #OVS Application level, until it had determined Egress Port
So in that Case, the MetaData are handled #OVS-Application level, until the Packets is send via Egress Port.
Is this correct??
Finally which Module in ODL is responsible for determine the Metadata, and I would like to understand from the code how exactly it was done.
The OpenFlow metadata field starts with a value of zero for every packets. Tables can then writes to this field and you can match on it in subsequent tables. It is only used to carry information from one table to the next, as explained in the OpenFlow specifications:
Metadata: a maskable register that is used to carry information from one table to the next.
first of all you can try Ryu instead, its code is more easy to read and understand.
Then, I think metadata/instructions/actions.... these things are belong to the processing of OVS forwarding, but these things needs to attach to something and that is the packet that OVS received. About the question "Do we have certain rule/ Algorithm , to determine these Metadata from a Packet. " I think the value of the Metadata is determind by the controller, which means that it depends on 'how do you design your own network instance using some(e.g. RYU) controller application'.