Inventory & BOM — From Chassis to Bill of Materials

The physical hierarchy, top to bottom

Every modular optical transport platform is the same five nested levels. Learn them as a strict containment tree — a fault, a spare, or an order line always lives at exactly one level, and naming the level removes most of the ambiguity in a support call.

A representative slot map

An Ekinops360-class chassis exposes a row (or rows) of service slots plus reserved positions for common/control and power. When you walk up to a node, the first artifact you produce is a slot map: which slot holds which card, and which are empty. Below is an illustrative two-site pair — the exact slot count, numbering, and reserved positions differ by chassis and must be verified against official documentation.

Illustrative only. Slot numbering, reserved-slot rules, and the number of service slots vary by chassis variant — verify exact SKUs, capacities, and slot rules against current official Ekinops documentation.

How compatibility constrains the design

You cannot drop any card into any slot or any optic into any port. The design is boxed in by several compatibility axes at once, and every one of them is a place a turn-up can fail if you skipped the check. Learn them as a checklist you run mentally every time you spec a port.

Inventory discovery on an existing node

Before any change, restore, or expansion you inventory what is actually installed — not what the design says, what is there. The management system's inventory export is the fast path, but you verify against the physical shelf for anything that will drive an order or an RMA. Record every level of the hierarchy. The table below is the shape of the record you produce; the values are illustrative.

Representative/illustrative inventory listing — serials, firmware strings, and channel labels are fabricated placeholders in a generic format. Do not treat as captured data. Verify exact SKUs, capacities, and compatibility against current official Ekinops documentation.

Building a BOM from a requirement (worked example)

Now the reverse direction: turn a stated need into an orderable list. The discipline is to decompose the requirement into services, map each service to functional cards and optics, add the line system and amplification the span demands, add the common/management and power infrastructure, then apply spares and list the open questions. Do it in that order every time.

Step 1 — Decompose into services

Six services total, each present at both ends (a service needs a card/optic at site A and site B):

• 2× 100G client service → 2× 100G transponder/muxponder function per site
• 4× 10G client service → 10G transponder function(s) per site, sized by how many 10G tributaries a card carries (a muxponder may aggregate several 10G clients onto one line wavelength — verify card capacity against official docs)

Step 2 — Map services to cards and optics

*Card count for the 10G services depends on tributaries-per-card — one muxponder may carry all four 10G clients on a single line wavelength, or you may need multiple cards. Verify exact SKUs and per-card capacity against current official Ekinops documentation. All quantities illustrative.

Step 3 — Add the line system and amplification

A ~70 km span drives the optical-layer decisions. Whether it needs amplification, a passive mux/filter, or a full OADM/ROADM depends on the span loss budget, the number of channels, and future growth. For a two-channel-plus point-to-point at 70 km you must check the loss budget against the line optics' reach: coherent 100G line optics often close moderate spans unamplified, while adding channels or margin may call for a line-amplifier module. Never assume — run the loss budget.

Step 4 — Add common, management, and power

Step 5 — Apply spares and roll it up

Add spares for the field-replaceable, service-affecting items (a spare of each card type carried, a few of each optic type, a spare power module). A common rule of thumb is one spare per card type per site or per region — your sparing policy governs. Then present the whole thing as the functional BOM below.

Functional BOM, illustrative quantities only. No SKUs or part numbers are given because exact models depend on official Ekinops product selection — verify exact SKUs, capacities, and compatibility against current official Ekinops documentation.

Step 6 — The open questions (resolve before ordering)

A BOM is not orderable until these are answered. Half of a good engineer's value is asking them before the PO goes out.

• Loss budget: what is the measured/expected span loss at 70 km (fiber type, splices, connectors, aging margin)? Does the chosen line optic close it, or is a line-amplifier module required?
• 10G aggregation: can one muxponder carry all four 10G clients onto a single line wavelength, or do we need multiple cards/wavelengths? This sets both card count and channel-plan consumption.
• Wavelength plan: which specific channels are assigned, and is the OADM/ROADM/mux compatible with them? Are the line optics fixed or tunable?
• Growth: is this the final size or a phase 1? Slot count, mux/ROADM type, and amplifier headroom should be sized for the roadmap, not just today.
• Redundancy: is control-card and power redundancy required? Is any service protected (which drives extra cards/paths — see the Protection page)?
• Client handoff: what exact client optics/connectors do the customer routers present (form factor, connector, single/dual fiber)?
• Firmware/licensing: what minimum firmware and which feature licenses does each card need, and are they included?
• Sparing policy: what is the agreed spares depth and location (on-site vs regional)?