4-channel dual-redundant MIL-STD-1553 parser/packetizer
2-channel dual-redundant MIL-STD-1553 parser/packetizer
This is a presentation on MIL-STD-1553 bus monitoring in Axon. There are two MIL-STD-1553 bus monitors in Axon - the AXN/MBM/401 which is a four-channel dual-redundant MIL-STD-1553 parser packetizer and the AXN/MBM/402 - a two-channel dual-redundant MIL-STD-1553 parser packetizer module. At the module level, there are parameters for report, bus active, and module temperature. The report parameter indicates the error condition, what bus the error occurred on, whether it be the primary or secondary channel of each bus, and up to 31 error codes. the bus active parameter indicates which buses are currently active and the module temperature parameter can be used for system health monitoring. These are parameters report, bus active, and module temperature.
For each channel, there are parameters for message count, error count, and words per second count. The message count is a count of all good 1553 messages received on each individual channel. The error count is a count of all errors detected on each individual channel and the words per second count is a count of MIL-STD-1553 message words received on each channel in the last second. You can see these here as message count, error count, and words per second. There are settings on each channel for maximum response time and accept TX or RX messages with no status.
For maximum response time, MIL-STD-1553 allows for eight to 31 microseconds for an RT to respond to a BC command. The user can configure the time to wait before a lack of response is considered an error. The user can configure the module to accept or reject messages with no status word. These can be seen here. Maximum response time, messages with no status, and TX messages with no status. The Axon MBM modules are parser packetizer modules. Talking about the parsing functionality, first of all, this is the ability to cherry-pick specific 1553 messages off individual buses.
The user defines rules to identify specific messages - there are 4095 rules on the 401 and 2047 rules on the 402. Rules can be defined based on 10 different message types. You can have BC to RT messages, BC to all RTs, RT to BC, RT to RT, RT to all RTs, mode code messages with no data, mode code messages that transmit data, mode code messages that receive data, broadcast messages with no data and broadcast mode codes that receive data. For every message type there are tag and info parameters. These are message count, command, word one, status one, response time one, command two, status two, response time two, then there are message info which is stale, skipped, or empty information and then there is message time which is available in 48-bit parameter or three 16-bit parameters - high, low and microtime. You can see these types of parameters here.
The Axon MBM modules also support variant functionality. To explain this, there can be only one bus controller active on a MIL-STD-1553 bus at any one time. However, during normal operation, the bus controller can relinquish control of the bus to another capable RT, hence the dynamic bus acceptance bit and the status word. The implication of this is that the expected BC to RT messages can change for example to RT to BC or RT to RT where the RT becomes the transmitting device. The Axon MBM modules support monitoring this behavior through the use of variant messages. The user defines a master message and multiple variant messages attached to this master message.
The data from this master message and all its variant messages get written to the same partial slot or memory location on the AXN/MBM/401 or 402. As an example, we have a master message defined which is a BC-RT to RT 2 sub address 20 with 32 data words and we have the parameters defined to capture this message. Under that, we have two variant messages defined. This is the RT-BC from RT2 sub address 20 or an RT to RT from RT2 sub address 20 to RT3 sub address Data from the master message and the two variant messages all end up in the same parameters defined for the master message. This is our master message and these are our two variant messages.
So the data from this master message and these variant messages all end up in the payload parameters defined for the master message. The MBM/401 and 402 are also packetizer modules - this can be done simultaneously to the selected data of the parser. There are three options for the capture of 5053 messages - this individual mode, dual redundant mode, and dual-stream mode. In individual mode, you get a separate ethernet stream for the traffic on Bus A and Bus B of each channel. In dual redundant mode, you get a single ethernet stream for Bus A and Bus B combined on a first valid wins basis and in dual-stream mode you get a single stream for Bus A and Bus B in dual redundant mode with the packetizer filtering applied and you get a single stream for Bus A and Bus B in dual redundant mode with no filtering applied.
You can see the settings here for the packetization type - individual, dual redundant, or dual-stream. the MBM/401 and 402 support packetizer formats into iNET-X and Chapter 10. In iNET-X mode, you have to input a unique stream ID, enable the packetizer, and set the packet timeout and payload size. When changed to chapter 10 mode you choose which UDP transfer header format you want, whether it be format one, format two, or format three. Under format three the source ID is eight bits and defined here. Under format one and format two the channel ID is 16 bits and defined here, again must be unique per channel. The MBM/401 and 402 also support filtered packetizers. This is the ability to control which traffic gets into the packetizer stream.
The three options are pass all, pass by rule, and block by rule. Under pass all, all messages received are packetized into the ethernet stream. Under point set to pass by rule, only those messages with the filtering rule enabled are written into the ethernet stream so in this example just these three messages will be packetized. The other ones will be blocked. Under block by rule, only the messages with the packet as a filter will be blocked so in this setup these three message definitions will be blocked and these two options that are not enabled will be packetized.
The Axon MBM/401 and 402 also allows the user to define where the packetizer traffic goes. You can send it to the controller only, you can send it to a specific slot or you can send it to everywhere. Under controller, only the packetizer packets are routed to the ethernet ports of the BCU only. When set to a specific slot the packetizer packets are routed inside the axon chassis to a specific slot as defined by the user - for example you could send them just to a recorder or a Chapter 7 PCM module, depending on what module you have in that slot. When set to all, the packetizer traffic is routed to the BCU and all other user modules so you can record and transmit simultaneously. This is configured here under packetization sync. So set to all, set to controller only, or set to a specific slot.