Inspect the source
The ARSAS application, ARIEC61850 engine, commit history and public issue trail are visible. Open source means the implementation can be reviewed—not that correctness is assumed.
Open ARSAS source →Authority · evidence · engineering boundary
Technical review is part of the product—not decorative copy.
ARSAS documentation distinguishes what the current software visibly demonstrates, what depends on relay support or project permissions, what is still preview quality, and what remains roadmap intent.
Open-source reliability
Trust the exact release because its evidence can be inspected.
ARSAS does not ask you to trust a logo or a black box. Source, package identity, automated regression evidence and field boundaries remain independently reviewable.
Verify the exact package
Stable v1.6.41 is tied to source commit e581a26dea5545034378adbeed5b78fc80aab773. The tagged release publishes SHA-256 checksums, an SPDX SBOM and provenance evidence for the release assets.
Make changes prove themselves
Application regression tests, Smart Discovery production-route guards, website/evidence validators and release checks run in CI. They catch regressions inside their declared scope; they do not simulate every physical relay.
Inspect CI history →Keep field claims bounded
Compatibility evidence is published per service and condition. Known limitations, negative outcomes and cases requiring physical-relay validation stay visible instead of being converted into broad compatibility claims.
Review field evidence →What this does not mean:Open source is not automatic correctness. CI is not FAT/SAT acceptance. A supply-chain attestation is not a reproducible-build claim. ARSAS exposes enough evidence for engineers to review the exact release and decide what still requires independent field verification.
Claims must point to inspectable behavior.
- Current application screenshots and visible UI states
- Deterministic source and rendered-site validation
- Tagged release package identity, SHA-256, SPDX SBOM and provenance evidence
- Exact source commit, source history, CI regression evidence and implementation boundaries
- Published July 2026 field profiles are historical; their capture-version is not publicly recorded and a retest on v1.6.41 is not documented. Review service-level scope and trace evidence to an exact release.
Evidence narrows causes; it does not replace project acceptance.
- Final conclusions depend on the approved design and test procedure
- Vendor-specific behavior must be checked against vendor documentation
- Network access, permissions and IED configuration remain project inputs
- Independent verification remains required where the project demands it
Claim governance
Four labels keep product communication honest.
ARSAS pages and guides are written to preserve the difference between implemented behavior and future intent.
Implemented and inspectable
The workflow is present in the current software and can be examined through the application, release artifact or source.
Depends on device or project conditions
Support can depend on IED services, writable attributes, network capture access, control model, permissions or configured engineering data.
Useful but still maturing
The workflow is available for evaluation while interoperability breadth, UX or diagnostic coverage continues to mature.
Planned, not promised as current
Roadmap content describes direction and is never presented as part of the current stable capability set.
Ari Sulistiono
Ari Sulistiono creates and maintains ARSAS and reviews the public product pages for practical IEC 61850 laboratory, FAT, SAT, commissioning and troubleshooting use.
Review follows product change.
Capability pages are reviewed when implementation scope changes. Troubleshooting guides retain a visible review date and are updated when diagnostic behavior, terminology or engineering boundaries materially change.
Verified stable · ARSAS 1.6.41
Ready for an approved Windows workstation?
Installer and portable packages share the same application scope. Verify the published SHA-256 and review the release boundary before field use.
Release notes, limitations and signing status →