Skip to main content
Glama

Arc Flash Platform — Estudos Elétricos

Energia incidente de arco (IEEE 1584 / NBR 17227)

calcular_energia_incidente
Read-only

Energia incidente (Ei, cal/cm²), LAS e a tabela de EPI da NBR 17227 de um arco elétrico, pelo algoritmo IEEE 1584:2018 / ABNT NBR 17227:2025 da plataforma (208 V–15 kV), que reproduz os exemplos D.1 e D.2 do Anexo D da IEEE 1584:2018. config ∈ {VCB,VCBB,HCB,VOA,HOA}. O campo categoria_epi traz a tabela de EPI que vale para o Ei: diga "Tabela 11" ou "Tabela 12" da NBR 17227 ao usuário, e não "categoria", que é a escala do Anexo IV da NR-10 e da NFPA 70E.

Dois patamares de corrente (IEEE 1584:2018 §4.12): t_arc_s = tempo de eliminação da proteção na corrente de arco PLENA (Iarc); t_arc_reduzido_s = tempo na corrente REDUZIDA (Imin ≈ 0,88·Iarc). Como a corrente reduzida costuma limpar mais devagar (proteção de tempo inverso), o patamar reduzido com frequência GOVERNA o pior caso. Havendo dispositivo com curva inversa, forneça os DOIS tempos. Sem t_arc_reduzido_s, os dois patamares usam o mesmo tempo e vale o MAIOR Ei; em média tensão (> 0,6 kV) o reduzido pode governar mesmo assim (ex.: 13,8 kV, 20 kA, 150 ms).

larg_mm/alt_mm/prof_mm = invólucro REAL do equipamento (a correção de tamanho da §4.8 muda o Ei; default = caixa de referência 508³).

Faixa de validade do modelo (NBR 17227 §5.2.2): com largura do invólucro ≤ 4 × gap (VCB/VCBB/HCB) ou distância de trabalho < 305 mm, o Ei sai, mas é EXTRAPOLAÇÃO: a resposta traz fora_da_faixa_do_modelo: true, validado: false e as condições em faixa_do_modelo. Diga isso ao usuário junto do número. avisos traz o tempo limitado a 2 s e a baixa potência.

A resposta declara criterio_ibf: "informado_pelo_usuario": a Ibf é a que você passou. Se veio de calcular_curto_circuito/montar_rede, é a máxima IEC 60909 (c_max); qualquer outra base (mínima, 1,0 pu) é escolha sua e deve ser dita ao usuário. Gratuito (uso limitado).

Input Schema

NameRequiredDescriptionDefault
alt_mmNo
configNoVCB
gap_mmYes
ibf_kaYes
api_keyNo
larg_mmNo
prof_mmNo
t_arc_sYes
tensao_kvYes
dist_trabalho_mmYes
t_arc_reduzido_sNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / alt_mm
      Added value: +{
      +  "default": 508,
      +  "title": "Alt Mm",
      +  "type": "number"
      +}
    • addedInput schema / properties / larg_mm
      Added value: +{
      +  "default": 508,
      +  "title": "Larg Mm",
      +  "type": "number"
      +}
    • addedInput schema / properties / prof_mm
      Added value: +{
      +  "default": 508,
      +  "title": "Prof Mm",
      +  "type": "number"
      +}
    • addedInput schema / properties / t_arc_reduzido_s
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "T Arc Reduzido S"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, so the description carries the behavioral load and does so: it discloses the validity-range extrapolation behavior (`fora_da_faixa_do_modelo`, `validado`, `faixa_do_modelo`), the `avisos` entries for the 2 s time cap and low power, the `criterio_ibf` provenance marker, and that the call is free with limited usage. An agent knows what it will get back and what caveats to relay.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and primary outputs are front-loaded in the first sentence, and subsequent paragraphs each carry distinct operational information (two-tier timing, enclosure dimensions, validity range, Ibf provenance). It is dense and long for a description, but almost no sentence is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters, 0% schema coverage and no output schema, the description compensates fully: it explains input meaning, the response fields worth relaying (`categoria_epi` vs. NR-10/NFPA 70E categoria, `avisos`, `faixa_do_modelo`, `criterio_ibf`), and even the wording to use with the end user. Nothing an agent needs to call and interpret this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate and largely does: it enumerates `config` ∈ {VCB, VCBB, HCB, VOA, HOA}, explains `larg_mm`/`alt_mm`/`prof_mm` as the REAL enclosure dimensions subject to the §4.8 size correction (default 508³ reference box), and distinguishes the two arc-duration parameters by full vs. reduced current. `gap_mm` is only referenced obliquely in the 4× gap rule and `api_key` is never mentioned, leaving minor gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource (incident energy, arc-flash boundary and NBR 17227 PPE table from an electric arc) plus the governing algorithm (IEEE 1584:2018 / NBR 17227:2025) and the 208 V–15 kV applicability window. That window implicitly separates it from calcular_energia_incidente_hv, but the sibling is never named, so an agent must infer the split.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete conditional guidance: supply both `t_arc_s` and `t_arc_reduzido_s` when an inverse-time device exists, otherwise both tiers use the same time and the larger Ei governs; also warns that the reduced tier can govern even at >0.6 kV. It names the upstream alternatives for Ibf provenance (calcular_curto_circuito / montar_rede) but does not explicitly state when NOT to use this tool versus the HV sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources