Exercises — MIL-STD-1553 — military avionics bus

Yeh ek Remote Terminal (RT) hai. 1553 mein exactly ek Bus Controller (BC) hota hai aur woh bus time ka har microsecond apne paas rakhta hai. Ek RT ek slave hai: yeh sirf usi command word ke response mein transmit karta hai jo usse address ki gayi ho. Pehle bolne ka matlab hoga do devices ek saath baat kar rahe hain — ek collision — jo command/response design construction se hi forbid karta hai.

• RT Addr = 7 → device number 7 ko address karo.
• T/R = 1 → Transmit: RT ko data bhejna chahiye (1 = transmit, 0 = receive).
• Subaddr = 2 → apne sub-channel 2 se.
• Word Count = 4 → 4 data words bhejo.

Simple English: "RT #7, mujhe apne subaddress 2 se 4 words bhejo."

Yeh Manchester II encoding hai. Jo problem yeh solve karta hai woh hai receiver clock drift: identical bits ki lambi run (jaise 100 zeros) plain NRZ mein koi edges nahi deti, toh receiver yeh track kho deta hai ki bits kahan shuru hoti hain. Har $1\mu s$ pe guaranteed mid-bit edge PLL ko locked rehne deta hai. (Dekho Manchester Encoding.)

$20\text{bits}\times \frac{1\mu s}{\text{bit}}=20\mu s.$ Ek word = $20\mu s$. Yeh har timing calculation ka atom hai.

Timeline pe har word aur gap gino (red bracket = total):

Total = ==$204\mu s$==.

(Parent note ne $8\mu s$ gap use karke $208\mu s$ nikala tha; $4\mu s$ minimum gap ke saath hum $204\mu s$ paate hain. Formula identical hai — sirf gap value badi.)

Time used per second: $204\mu s\times 50=10,200\mu s=10.2\text{ms}.$ Ek second $1,000,000\mu s$ ka hai, isliye: $\frac{10,200}{1,000,000}=0.0102=1.02\%.$ Bus lagbhag 1% busy hai. Bahut jagah baaki hai — exactly isliye 1 Mbit/s chhote messages ke liye kaafi hai.

Manchester II mein har bit mein ek mid-bit edge hoti hai, isliye bina transition ke sabse lamba stretch ek edge se pehle half bit plus agli ke baad half bit hota hai — worst-case adjacent bits mein forced edges ke beech zyada se zyada ek full bit-time, yaani same level ke $\le 2\mu s$. Ek sync poore $3\mu s$ ke liye ek level hold karta hai, jo us limit se zyada hai. Kyunki data $3\mu s$ ka flat level produce nahi kar sakta, receiver isse guaranteed word boundary treat karta hai — koi data pattern kabhi ise imitate nahi kar sakta.

• Single bus: $P=p=0.002$ (0.2% per hour).
• Dual redundant: comm tab hi lost hoti hai jab dono fail hoon: $P=p\times p=0.002^2=0.000004=4\times 10^{-6}.$ Improvement factor: $\frac{0.002}{0.000004}=500.$ Dual redundancy 500× safer hai yahan. (Independence key assumption hai — shrapnel dono wires ko saath kaatne se yeh violate hoga, isliye dono buses physically alag route ki jaati hain.)

$V_{\text{diff}}=(V_A+\Delta V)-(V_B+\Delta V)=(5+3)-(-5+3)=8-2=10V.$ Noise $\Delta V=+3V$ dono terms mein appear hoti hai aur subtract ho jaati hai. Receiver phir bhi $+10V$ (ek clean logic 1) read karta hai. Yeh common-mode rejection hai: noise jo dono wires pe equally hit kare woh difference mein cancel ho jaati hai. (Wohi principle jaise RS-485 Protocol.)

(a) Minor frame. Sabse fast rate 100 Hz hai, isliye base period $1/100=10\text{ms}$ hai. Har $10\text{ms}$ frame mein: RT-1 har frame mein chalta hai, RT-2 har 2nd frame mein (50 Hz), RT-3 har 4th frame mein (25 Hz). Minor frame = ==$10\text{ms}$==.

(b) Transaction lengths (read = cmd + gap + status + N·data; write = cmd + gap + N·data + status; dono mein data ke aage 2 words ki overhead plus ek gap hai):

• RT-1 read, 4 words: $20+4+20+4\times 20=124\mu s$.
• RT-2 read, 16 words: $20+4+20+16\times 20=364\mu s$.
• RT-3 write, 2 words: $20+4+2\times 20+20=84\mu s$.

(c) Worst-case frame. Sabse busy frame woh hai jahan teeno ek saath aate hain (har 4th frame, kyunki RT-3 sabse slow hai). Us frame mein hai: $124+364+84=572\mu s.$ Worst frame mein utilisation: $\frac{572}{10,000}=0.0572=5.72\%.$ Worst-case bus load = 5.72%. Comfortably schedulable hai (dekho Real-Time Scheduling Theory aur Time-Triggered Architectures).

Worst case = teeno attempts hote hain (2 fail, 3rd bhi fail ho sakta hai give up se pehle): $3\times 204\mu s=612\mu s.$ Worst-case = ==$612\mu s$==. Ek scheduler ko yeh maximum budget karna chahiye, nominal $204\mu s$ nahi, warna ek noisy burst frame blow kar dega.

Decisive reason: raw speed irrelevant hai agar latency non-deterministic ho. Standard Ethernet (CSMA/CD, switch buffering) ek bounded worst-case delay guarantee nahi kar sakta — collisions aur queueing unpredictable jitter add karte hain, isliye tum $500\mu s$ bound prove nahi kar sakte. 1553 ka command/response schedule latency ko microsecond tak provable banata hai. Modern high-bandwidth choice: AFDX (Avionics Full-Duplex Switched Ethernet), jo latency bound karne ke liye bandwidth reservation add karta hai — bulk sensor data ke liye use hota hai jabki 1553 critical control loops pe rehta hai. Contrast karo CAN Bus aur ARINC 429 se bhi, jo alag determinism trade-offs rakhte hain.

Ek se do buses jaane se comm-loss probability $p$ se $p^2$ tak cut hoti hai — ek bada, sasta win. Do se teen jaane se yeh $p^3$ tak aur cut hoti hai, lekin $p$ already tiny hone ke saath (maan lo $10^{-3}$), $p^2=10^{-6}$ already Level A ki requirement clear kar deta hai. Teesri bus $10^{-6}$ se $10^{-9}$ tak improve karti hai — mission se zyada reliability, extra weight, wiring, transceivers, aur validation effort ki cost pe. Avionics mein, weight fuel hai aur cost schedule hai; tum exactly utni reliability khareedete ho jitni certification demand karti hai aur kuch nahi. Yeh diminishing returns meeting a fixed requirement hai.

(a) RT-4 read, 32 words (yaad raho word count 0 encode karta hai 32, maximum): $20+4+20+32\times 20=684\mu s.$ (b) RT-4 har frame mein chalta hai, isliye yeh worst frame mein add hota hai (4.1 ka $572\mu s$): $572+684=1256\mu s.$ Utilisation: $\frac{1256}{10,000}=0.1256=12.56\%.$ (c) 12.56% pe bus abhi bhi easily schedulable hai — 87% idle margin baaki hai, retries aur future growth ke liye bahut jagah. Design close ho jaata hai.