How do I design and implement SNMP?

Most likely they cannot. (Unless there is SNMP over USB or Modbus) They will have to notify the main PC controller, which in turn will generate the traps.

1st, understand the protocol:

(Old but still useful.)

( If you can find a copy of the original SNMP "Yellow book", that's very good )

2nd, implement a simple/sample system on a couple of PCs, one acting as an SNMP agent, the other as a controller.

3rd, apply what you learned on your real target.

My crystal ball is foggy at this moment, I can only see the words "More than ..."

--
Roberto Waltman 

[ Please reply to the group, 
  return address is invalid ]

Forgot to add,

You don't mention what your operating system / environment is. There are several commercial libraries that can substantially reduce your development time - after you understand the basics.

--
Roberto Waltman 

[ Please reply to the group, 
  return address is invalid ]

So, the "several embedded controllers" are the SNMP agents reporting

*to* the "Embedded Gateway Controller" (EGC). The EGC acts as the network management system. How *that* EGC communicates with the hosting (?) PC is beyond the scope of this current question... (possibly polled?)

But, these are talking CAN? SNMP is designed as an "over ethernet" (specifically UDP) protocol. First off, you'll design and implement some middleware that makes one look like the other? (your choice of which does the active masquerading).

(I'm assuming you've sorted out how to get to a point where SNMP "makes sense" in your design...) The MIB support can probably be lifted from some FOSS project. That isn't "hard" but it can be tedious supporting arbitrary namespace hierarchies. (*designing* those hierarchies is a challenge specific to *your* application domain!)

I'm still not sure I see a *practical* way forward for you. Has someone *imposed* this requirement on you/your system -- without concern for the system's actual implementation? Or, are you "fishing" for a possible mechanism to implement some feature/capability but, perhaps, imperfectly knowing about it's suitability?

Without knowing what the normal communications flow in your system looks like... can you find some point in your existing protocol(s) where you can *regularly* exchange status/command information associated with management functions? I.e., the equivalent of get/set request and *polled* traps?

Look at what your components normally "say" to each other. What and when. See if there is an easy way to wedge in some "overhead" for this management task AS PART OF THE NORMAL EXCHANGE OF COMMAND/DATA.

E.g., perhaps a status field that is present in each message *from* an embedded controller that alerts the EGC that this controller has some "exception" to report. Then, let the EGC poll that controller for more details.

It's hard to know what sorts of information you will be exchanging and the timeliness of that information in order to suggest more appropriate mechanisms... E.g., getting that information up to the PC (which, presumably, will log or report it to ).

HTH,

--don

From his original post, it seems he was trying to implement SNMP *below* the "Embedded Gateway Controller" (EGC). I.e., to let his individual "embedded controllers" (unfortunately, name chosen -- by him -- makes the distinction a bit blurry) report traps to the EGC which, possibly, acts on them *or* eventually reports them to the PC (by some *other* mechanism not addressed in his post).

I think the problem is more fundamental than this. It appears he is trying to take a technology from one domain (ethernet) and apply it to another domain (CAN) without having sorted out the basics of that mechanism *in* that new domain.

Sort of like saying you want to run a WWW service on one of those "embedded controllers" -- yeah, there is probably some *parallel* that can make sense in that domain but you've got a lot of *basic* steps to resolve between "apache" and "CAN-pache"! :>

I think "Concentrate and ask again" is more appropriate... (or, perhaps, "Reply hazy try again" if you want to be generous!)

--don

I would start with A Practical Guide to SNMPv3 and Network Management ISBN: 0-13-021453-1

dp/0130214531

There are others but I found this one OK. Read it completely, then read it again. Then ask yourself, what MIB will I be implementing on the controller and how is that controller going to send a trap over CAN and how will the gateway forward the traps. Then read the book again. Then get a book on MIBs. There are several out there.

It takes a lot more than just sending a trap for this to be useful.

Also, you are going to "get" to learn a new language - ASN.1 enjoy.

--
Chisolm 
Republic of Texas

I did not read it that way, but that is a plausible implementation. I assumed, (make all of the following requests for clarification.)

(a) There is no SNMP at the controllersgateway level.

(b) There is a standard UDP based SNMP protocol running between the gateway and some not yet mentioned external system.

(c) The gateway is the SNMP agent and acts as a proxy for the controllers, which are represented by a set of MIB OID's.

(d) The controllers notify the gateway when "significant events" happen. The gateway generates SNMP traps, again, referring to the controllers by MIB OID only.

Let me try again ... Dust it off, shake, put on the table, light a candle , wait ... Now I can discern "Much More Than ...

--
Roberto Waltman 

[ Please reply to the group, 
  return address is invalid ]

Previously, you had said: "Our PC Application is connected to Embedded Gateway Controller over USB." So, I'll assume that was an error.

They will be *mapped* to SNMP traps *in* the Gateway Controller. I.e., they aren't SNMP traps WHILE ON THE CAN BUS.

OK. "Something" in the Gateway Controller will receive a message from the "embedded controllers" -- via some unspecified portion of your communication protocol. The Gateway Controller will recognize this report/message as requiring a *trap* to be reported TO THE PC (or anything else that speaks SNMP on the network that the Gateway Controller is connected to).

OK.

OK. "Something else" gets the events *to* the Gateway Controller from the embedded controllers. The Gateway Controller is the SNMP agent (possibly one of many) and the PC is acting as the network management system.

Free Open Source Software

Actually, I was talking about piggy-backing this information onto your *CAN* protocol. I.e., to enable the embedded controllers to tell the Gateway Controller when "something of interest" had happened.

But, the same thing can happen between the Gateway Controller and "whatever" it happens to talk to, normally (i.e., the PC).

Since the Gateway Controller can "talk ethernet", it could take advantage of any of a number of other mechanisms to report these "asynchronous/unsolicited" messages.

E.g., you could implement a small *mail* agent in the Gateway Controller and have it send an *email* message to for each such "trap".

A lot depends on what the role of these alerts are to be. And, how often they are expected to occur. E.g., if it is an infrequent event like "the backup battery in embedded controller #3 needs to be replaced in the next few days", then email can make sense.

OTOH, if it is a more frequent event that requires a more interactive remedy ("Log memory is full on embedded controller #5 and it needs to be spooled off to archival storage"), then you may opt for a protocol/mechanism that provides shorter turn-around times. Or, something that is more directly geared towards "automation" (in this example, to initiate a process/program that dumps the log from controller #5 and then restarts it)

Well, over IP via UDP, anyway. Ethernet is not a requirement at all.

Although later messages from the OP clarify his problem somewhat, there have been a number of efforts to define a standard IP-over-CAN mapping, dating back to at least 2000. I don't think any have made it even to the IP standards track, though, much less become actual standards. But if you wanted to do such a thing, at least several of those looked reasonably well though out, and none was very complex, so just running with one would probably work in most cases.

...

I do not know what you are using the PC Application and Modbus for - building automation?

-

Have you thought about using BACnet (goes over nearly everything)?:

Open-Source BACnet Protocol stack for Linux:

Open-Source BACnet Protocol stack for embedded systems:

Open-Source BACnet Protocol stack in Java:

BACpypes, Open-Source BACnet Protocol stack in Python:

BACsharp, Open-Source BACnet Protocol stack in C#:

/Glenn

Was going to suggest a Google search, but after reading again previous posts I would take that recommendation back.

SNMP agent libraries can automate message parsing and generation, create stub functions for all objects defined by a product's MIB, provide debugging facilities, etc., and update everything mechanically whenever there is MIB change.

But if you only need to generate traps, that may be an overkill. The open source libraries I posted before will provide you with the functionality needed to encode and decode SNMP messages. using them directly may take less time than mastering a do-it-all library.

I would ask the marketeers to specify the complete MIB tree that the product must support, that will give you a better feeling for the work involved.

You will need a few standard objects plus the capability to enable and disable traps, (may be more than one type,) , specify the trap destinations, etc.

--
Roberto Waltman 

[ Please reply to the group, 
  return address is invalid ]

try

tools.

my

as

in

any

we

events

In our powerpoint slides there is a picture of building that is connected to Gateway Controller(our arm7 based embedded

target boarad) via SNMP. Gateway Controller is connected to other embedded controllers via CAN and Modbus RTU. SNMP

communication is between the building and Gateway.

Yes, they'll be mapped to SNMP traps in the Gateway Controller. They aren't SNMP traps while on the CAN Bus.

Controller

such

I've never implemented small *mail* agents. How can I learn to implement this small *mail* agent?

Is implementing small *mail* agent much less effort than implementing SNMP traps?

I'll find out how often will these alerts occur?

--------------------------------------- Posted through

So, the embedded controllers are *inside* the building -- running HVAC, security, or . When "exceptions" occur (whatever those might be!), an embedded controller "alerts" the Gateway Controller (somehow identifying the nature of the exception in a way that makes sense TO THE GATEWAY CONTROLLER). The Gateway Controller converts this to an SNMP trap that it reports to the NMS (a PC, somewhere).

Presumably, these are mainly "enterpriseSpecific" traps? (i.e., "other"). Or, are you actually interested in reporting network interface activity, reboots, etc.?

Aside from traps, do you also need the other capabilities that SNMP (potentially) affords you? E.g., the NMS could conceivably command the Gateway Controller to change its IP address/mask, point it at a different DNS server, etc. I.e., SNMP is more than just reporting traps (asynchronous events).

Apples vs. Oranges. They are different approaches to similar (though possibly different) problems.

For example, an SMTP agent talks TCP while SNMP transactions are UDP based. As a result, the agent/client in an SNMP transaction has to layer any acknowledgements/timeouts on top of the protocol while SMTP has the benefit of the connection-oriented protocol.

Though this can also be seen as a disadvantage -- SMTP requires a larger stack (i.e., if your Gateway Controller doesn't need TCP for any other purpose, you could trim its network stack down to just support UDP -- pretty simple!

*You* have to decide what your product needs and where you want to spend the effort. E.g., if you send a trap to the SNMP NMS and the UDP message gets lost, do you care? Do you implement some acknowledgement protocol on top of the trap delivery? With the mail approach, you at least know that the message was delivered (even if it gets lost thereafter).

You also have to decide where these "alerts" need to go. E.g., sending a trap to a cell phone isn't going to happen "out of the box". OTOH, you could configure the Gateway Controller to send email messages to any address you choose and count on existing infrastructure to send it to its desired destination (even if that happens to be a cell phone).

It's too hard to compare one approach to another without knowing the specific needs of your application (that's *your* job!). I'm just trying to alert you to the different possibilities that can present themselves...

On Sat, 20 Jul 2013 22:34:14 -0500, janii wrote: [snip]

Is the computer in "the building" running your own software? If it is then using a trap is probably not necessary. However, if that software in "the building" is some enterprise management system like a BMC product that might be monitoring a full data center, and the marketing folks want you to talk that that, then you have a much bigger issue. If you are the small player in the mix you will have to play nice with these management systems. These days people will say "Network Management Systems" but they are much more than "Network". They many be monitoring servers, heck even VMs on a server, the UPS, doors on buildings (We had doors on our equipment shelters wired so they would trigger a management system alarm - the NOC map had them on it).

Just sending a trap to these systems is like me sending you a email message "glue fox water well glass coffee cup". It means nothing unless you have the decoder ring. The MIB is the decoder ring for the management system. There are standard MIBs you might be able to use, but you have to be able to supply this information to the management system folks so they can configure their system to understand your box - your gateway.

The management system will want to talk to your gateway, not just get traps. They may do discovery to find out who is out there on the network. They will do periodic gets of sysUpTime or some other common variable to make sure they can communicate with your gateway.

Not sure what your modules and gateway do but if it is alarm related you might want to look at RFCs 3877, 3413, 3014 for starters.

There are a lot of examples of mail clients (agents) out on the web and else where. Heck, if your company mail server is listening on port 25 just: telnet yourcompanymailserver 25 and you become a mail agent - just have to know what to type - see the RFCs at

Remember - a mail client (agent) has to send email TO someone via a mail server. That mail server might be running on a box in the "building" on the power point slide. Something is going to have to process (read) that mail message when it gets to the "building".

Don has shown you a great way to notify one to many people and processes that something has happened in your system.

Find out why the powerpoint slide says "SNMP" first.

--
Chisolm 
Republic of Texas

Exactly - The requirement may be to interact with an existing SNMP based monitoring and control system. (So the suggestion to use alternatives such as email is not acceptable.)

--
Roberto Waltman 

[ Please reply to the group, 
  return address is invalid ]