Environmental noise, calculated clause by clause

A level that nobody can trace has to be checked again

A calculated noise level ends up in a permit, a zoning plan or a noise map. Somebody then has to trust it: the engineer who signs the study, the reviewer at the competent authority who assesses it, and whoever decides on it. The questions they ask are the same every time. Which text of the regulation was used, and which edition? How was a formula read where the text is unclear or contains an error? Where does the calculation depart from the text? And will the same input give the same number next year?

When those answers are not written down, the review falls back on the reviewer’s own experience, on recalculation, or on trust. Attenix is built so that each of those questions has a written answer that a reviewer can follow from the result back to the clause.

• For the engineer

  The method edition, the path finder and every version are named in each result. Problems in the input are reported before a long calculation starts, and an edit is recalculated without redoing the whole study.

• For the reviewer

  A traceability matrix lists the clause behind each formula; each reading of an unclear text is a numbered entry with the question, the options and the reason; each departure from the text is listed in a deviation register. None of it needs access to the source code.

• For the decision maker

  Results are reproducible to the bit, the checks run on every change, and this page says plainly what the first release does not cover.

Four questions, four written answers

Attenix keeps the texts it implements, the readings it chose and the evidence together with its code, and generates its documents from them, so that the documents cannot drift from what the code does. Each answer below names the document in which a reviewer reads it.

• Which text: every legal text and standard the engine implements has a Ref ID in a reference register, such as NL-OMGR-IVE for Bijlage IVe. Where reuse is allowed, the exact consolidated text is stored with a SHA-256 checksum that is checked automatically. A new version of a text goes next to the old one, so an older method edition stays tied to the text it implements. ISO standards and other copyrighted sources are referenced, never copied. Shown in the QA documentation of each module edition, which lists the dated references with their version and licence.
• Which formula: every formula in the implementation carries the Ref ID and the clause, equation or table it implements, and a check fails when a formula has no citation or cites an unknown source. Dutch legislation publishes its formulas as images, so each formula is transcribed once, and the implementation, the tests and the independent reference implementation all use that one checked reading. Shown in the traceability matrix of the QA documentation, generated from those citations, and in the formula reference, which sets each transcribed equation next to the entries that concern it.
• Which reading: where a text is ambiguous, contains an evident error or leaves a choice open, the choice is a numbered entry in an interpretation register, with the clause, the question, the options considered, the choice and its reason. Changing a choice changes results, so it needs a new implementation version of the module; the old version keeps the old choice. Shown in the interpretation register of each module edition and in the deviation register, which lists every entry that corrects, extends or limits the text and counts the ambiguities.
• Same input, same number: results are identical to the bit on every supported platform, independent of threads, tiles and hardware, and an incremental recalculation gives the same results as a full one. Shown in the manifest that every calculation writes, with the module edition, implementation version, parts and rule set it used; the same manifest replays the calculation.

What reviewers and customers get

The source code of Attenix is not public. What makes a result traceable is a set of documents that the engine generates from its code, its specifications and its registers, and that a check compares with them on every change. Some come with every calculation. The others form a QA package per module edition, kept unchanged per product release: it comes with a licence, and reviewers at competent authorities who assess a study calculated with Attenix can request it.

With every calculation

• Calculation manifest: written next to the results. It records the engine version; every module with its edition, implementation version, parts, signer and data tables; the path-finder rule set; the digest of the input and how it was imported; every parameter and setting; whether the run was full or incremental; and warnings, such as a calculation with a proposal that is not the text in force. Its SHA-256 digest identifies the calculation. Replaying the manifest reproduces the result with exactly the recorded versions, or refuses when one of them is not installed.
• Trace: when tracing is switched on for chosen receivers, every intermediate value of every path, meteorological condition and octave band, under the symbols of the method. The results are the same to the bit with and without it.

Per module edition: the QA package

• QA documentation: one document per module edition, in the sections that ISO 17534-1 (§5.1.1, §5.1.2, §5.2.2 and §6) asks of calculation software: the method and its dated references, how completely each calculation step is implemented, the general strategies, the reference configuration and the settings that can or cannot change results, the interpretations, the traceability matrix, the tools to check a calculation, uncertainty determination, the validation cases with their largest deviation, and how changes that can influence results are listed. The documents of a product release are kept unchanged.
• Validation cases: the cases built from the public texts, each with its input, its expected results and their tolerances, as ISO 17534-1 (§4.5.2) describes them, so that a reviewer can calculate them in another program or by hand and compare. Together with the manifest, which reproduces any result with the recorded versions, the evidence does not have to be taken on trust.
• Declaration of conformity: in the form of ISO 17534-1 (§6, Annex B), with the test-case requirements and the grade of implementation of each calculation step. It is Acrotron’s own declaration, not a certification, and it is generated together with test cases that are under licence and are not published.
• Method description: per module, how each edition calculates, in prose, with the differences between editions; each section cites the requirements and interpretation entries it describes.
• Formula reference: per module edition, every equation, table and figure the implementation cites, as transcribed, with its interpretation entries and their kind, and the trace quantities that record its terms.
• Interpretation register: per module edition and per path finder, every reading of an unclear text: its id, source and clause, kind (ambiguity, correction, extension or limitation), the question, the options considered, the choice, the reason, and the implementation version since which it applies.
• Deviation register: every correction, extension and limitation of every module edition, every calculation step implemented only in part or not at all, and the number of ambiguities per register.
• Change log: between two product releases, every change that can influence results: parts, rule set, interpretations, parameters, maximum distance and the stored reference results.

The documents never contain text or data of a privately licensed source, such as an ISO document: such sources are cited by Ref ID and clause only.

With the software

• Software bill of materials: every engine package and every installation of Attenix Studio contains an SBOM in CycloneDX, the standard format that IT departments and security scanners read. It lists every component with its exact version, its licence and a hash of its files, including the third-party code inside the engine, the libraries inside Studio’s map renderer and coordinate library, and the .NET runtime Studio needs. The same release gives the same SBOM. In Studio, Help ▸ About links to it.

The methods it calculates

A calculation method is a module. Each module has an edition per text of the regulation it implements, and each edition has its own implementation version. A result always states which of them produced it.

For road traffic in the Netherlands the engine implements both texts of the Omgevingsregeling, Bijlage IVe that apply in 2026: the text in force from 2024-01-01 to 2026-06-30 and the amended text in force from 2026-07-01. It also implements Standaardrekenmethode 2 of the Reken- en meetvoorschrift geluid 2012, which the transitional law keeps for provincial roads and industrial estates; the road lanes of both Dutch methods share one set of attributes, so one study can be calculated with either. For industry in the Netherlands it implements both texts of Bijlage IVh that apply in 2026, with method I for sources close to the receiver. For the European method it implements CNOSSOS-EU (Directive (EU) 2015/996 and its amendment by Delegated Directive (EU) 2021/1226) for road traffic, railway traffic and industry, each with the Dutch adaptation of Bijlage XXXIII.

Working with the engine

The command-line tool imports a scene from a GeoPackage once and calculates it with the module edition and path finder you name. With the installed tool:

$ attenix import input.gpkg scene.atxscene
$ attenix calculate scene.atxscene --module nl-omgr-ive@2026-07/1.0.0 \
    --path-finder nl-sector@1.0.0 --out results.gpkg

• GeoPackage exchange format: input and results are GeoPackage files in a versioned, documented schema that GIS software can open.
• Incremental recalculation: after an edit, only what the edit affects is calculated again, and the results equal those of a full calculation.
• Signed module packages: calculation methods are installed as signed packages; the tool loads only packages from its trust list.
• QSI data interface: attenix qsi import and qsi export exchange a model with programs that use the QSI data interface of DIN/TS 8998-1, the exchange format ISO 17534-1 refers to in Annex D: receivers, buildings, screens, terrain and ground areas, and sources as geometry only, since no method supplement of the standard covers the methods Attenix implements. What has no counterpart is reported.
• END delivery: attenix end export writes the Dutch delivery of strategic noise maps under the Environmental Noise Directive, in the 2026 templates of RIVM’s Centrale voorziening geluidgegevens (Cvgg), for an agglomeration or for major roads: contours of CNOSSOS-EU grid results at 4 m in the END classes, clipped at the municipal or provincial border, and the exposure tables from the numbers of people and dwellings the user gives. attenix end check checks any delivery file offline, also one made by other software. Both are checked against the documented Cvgg checks of the 2026 manuals, and the export writes nothing when its check finds an error.

One clause, followed through the documents

This is what those answers look like for one equation: the calculation height of a source behind a screen in the 2024 text of Bijlage IVe, where the printed text has two problems. The example is real. The entry and the table rows below are taken, shortened, from the documents of nl-omgr-ive@2024 that a reviewer receives.

1. The source text

   NL-OMGR-IVE-2024 §2.10, eq. 2.18a, as printed

   z′_B = z_B + Δz_B x = 0,75 (z_B − z_T + 0,25) Δz_B = 0,65 if x < 0 Δz_B = 0,4625 − 0,75 (z_B − z_T) if 0 < x < 0,65 Δz_B = 0 if x > 0

   The printed text has two problems: the second and third cases overlap for 0 < x < 0,65, and the sign of the first line differs from the text before it and the text after it.

2. The interpretation entry

   Interpretation register of nl-omgr-ive@2024

   INT-nl-omgr-ive@2024-020 — Overlapping cases and sign of eq. 2.18a (2024 text)

   Ref

   NL-OMGR-IVE-2024

   Clause

   2.10, eq. 2.18a

   Kind

   Correction. The printed text is read as an error, and the entry names the texts that support the corrected reading.

   Question

   For 0 < x < 0,65 both the second and the third case apply: which one? And the 2024 text prints z′_B = z_B + Δz_B, where the text before it (NL-RMG2012-III) and the amended text of 2026-07-01 have z′_B = z_B − Δz_B: which sign?

   Options

   Cases: the second case (a continuous Δz_B) or the third (Δz_B = 0 for all x > 0). Sign: + as printed, or − as in the texts before and after.

   Choice

   The second case for 0 < x < 0,65, the third for x ≥ 0,65; z′_B = z_B − Δz_B, the printed “+” read as a printing error.

   Rationale

   Only the second case makes Δz_B continuous, and the amendment of 2026-07-01 sets the bound of the third case to 0,65. The texts before and after have −, and RIVM’s calculation program for the 2024 text computes with −. The explanatory notes of the amendment call both a writing error.

   Since

   Implementation version 1.0.0

3. The registers and the traceability matrix

   Deviation register; QA documentation of nl-omgr-ive@2024, section 8

   Because the entry corrects the text, the deviation register lists it with the other departures from the texts:

   Deviation register, row for eq. 2.18a

   Source	Kind	Subject	Entry
   NL-OMGR-IVE-2024 §2.10, eq. 2.18a	correction	Overlapping cases and sign of eq. 2.18a (2024 text)	INT-nl-omgr-ive@2024-020

   The implementation of the screening part cites the clause, the equation and the entry. The traceability matrix of the QA documentation is generated from those citations, so it shows which code element implements eq. 2.18a and which entries it follows:

   Traceability matrix, rows for eq. 2.18a in the edition 2024

   Ref ID	Clause	Equation	Code element	Interpretation
   NL-OMGR-IVE-2024	2.10	eq. 2.18a	Screening2024	INT-nl-omgr-ive@2024-007
   NL-OMGR-IVE-2024	2.10	eq. 2.18a	Screening2024	INT-nl-omgr-ive@2024-020

   A check fails when the implementation cites an entry that does not exist, when an entry lacks one of its fields, or when a document differs from the one generated from the current code. Entry 007 assigns the boundary values x = 0 and x = 0,65 to a case, since the printed conditions are strict.

4. The result

   Manifest and trace of a calculation with nl-omgr-ive@2024

   Module

   nl-omgr-ive@2024, implementation version 1.0.0

   Part

   screening 2024/1.0.0

   Path finder

   nl-sector@1.0.0

   A changed reading needs a new implementation version, so the versions in the manifest say which reading of eq. 2.18a a result rests on. With tracing switched on, the calculation height z′_B of every screened path is recorded under its symbol, and a reviewer can check it by hand for a receiver. The QA documentation and the method description show the same correction, set apart from the source text.

How the results are checked

Traceability says what the engine is meant to calculate; the checks show that it does. Each check runs automatically on every change, except the ones that need licensed material or another program, which run locally.

• Analytical reference cases: validation cases for both editions of Bijlage IVe and of Bijlage IVh with its method I, for Standaardrekenmethode 2 of the RMG 2012 and for the CNOSSOS-EU modules for propagation, road traffic, railway traffic and industry with their Dutch adaptations, built from the public texts and calculated by an independent reference implementation from the same transcriptions. For CNOSSOS-EU they cover, among others, mixed ground, one and two thin screens, a building as a thick obstacle, reflections of the first and second order, all five vehicle categories of road traffic, and the bridges, joints and curves of railway tracks. The QA documentation lists each case with its largest deviation.
• ISO/TR 17534-4 test cases: the test cases for CNOSSOS-EU propagation pass with the edition 2015-996 that they test; edition 2021-1226 passes every case the amendment leaves unchanged, and its amended readings are checked against analytical cases. The cases come from a document under a single-user licence, so they run from a private corpus and are not published. Only the outcome of each run is recorded. In the run of 2026-10-08 all 56 cases (TC01 to TC28, with and without lateral diffraction) passed with edition 2015-996. Each release needs such a recorded run.
• Comparison with the Rekenhart geluid: nl-omgr-ive@2024 is compared with RIVM’s calculation program for the 2024 text, on scenes that include a cut, a fill, a viaduct, earth berms, several screens and a residential district, and on a real-world scene: 450 m × 450 m of Amersfoort built from open data (road centre lines, buildings and ground areas), with 366 receivers. Every difference is classified as a defect in Attenix, a choice of the program or an ambiguity of the text; the real-world scene found one defect in Attenix, which is fixed. This is a comparison with another program, not a conformity claim, and it does not imply endorsement by RIVM.
• Comparison with the industry Rekenhart: nl-omgr-ivh@2024 is compared in the same way with RIVM’s calculation program for industrial noise, on the analytical cases of Bijlage IVh and on two plant scenes with halls, a tank, a screen, open installations and five sources. Every difference is classified; none was a defect in Attenix. This is not a conformity claim either.
• Bit-identical results: every change is built and tested on Windows x64, Linux x64 and Linux ARM64, in both SIMD modes, against frozen golden outputs.

A study in Attenix Studio, from file to result

Attenix Studio is the Windows desktop application for building noise studies and calculating them with the engine. A study is a GeoPackage file in the engine’s schema, so the same file works in Studio, in the command-line tool and in a GIS.

Studio is in development. Every step below is built and works in the development build of 2026-10-08.

1. Open the study

   Built

   Studio opens the GeoPackage and shows its roads, buildings, screens, terrain and receivers on a map over the BRT background map, one layer per kind of object, with visibility, locks and opacity per layer and sub-layers to group objects. Saving writes back only what changed and leaves the rest of the file as it was. The image at the top of the page shows a study opened after a calculation. A study can also be made from a model in the QSI data interface of DIN/TS 8998-1 and written back as one (File ▸ Import and File ▸ Export ▸ QSI model…); the Problems panel lists what a model cannot carry.

   Files from outside the study can be shown under its layers as external layers: shapefiles in any EPSG coordinate system, and GeoTIFF files such as an AHN height model, coloured by height with an optional hillshade, or an aerial photo. The study keeps a reference to the file, never a copy, and shows when a file has moved, changed or gone missing. A large GeoTIFF’s display is built once in the background, shown coarse first while you keep working, and opens at once after that.

2. Inspect and correct the input

   Built

   Selecting an object shows its attributes in the Properties panel, with the unit and meaning of each column, and its geometry: the coordinates and height of every vertex, which can be typed or dragged as handles on the map, with snapping. The tool strip has a drawing tool per kind of object, grouped as sources, obstacles, terrain, ground and receivers. Every edit is a step in the History panel that can be undone, and an edit journal recovers unsaved work after a crash.

   Besides roads, the sources include industrial point, line and area sources, for CNOSSOS-EU or for Bijlage IVh, with their sound power per octave band, operating hours per period and, for Bijlage IVh, the surcharge for tonal, impulsive or music noise. Edit ▸ Directivity tables… keeps the study’s directivity tables, and a source takes one with its orientation. Attenuation zones (dense vegetation, open process installations) and tanks as cylinders are drawn for Bijlage IVh. Edit ▸ Convert layer to moves a layer of industrial sources between CNOSSOS-EU and Bijlage IVh in one step that Undo reverses.

   

3. See all objects of a kind side by side

   Built

   An object table lists every object of a layer in one data grid, with a filter on every column header, sorting and grouping, and export to CSV. A reviewer can sort all receivers by height or all buildings by their height and find the odd one out; the table and the map share the selection.

   

4. Check before calculating

   Built

   Check study (F7) checks the study as it is, unsaved edits included, with the rules a calculation applies, without calculating it and without changing the file. The Problems panel lists each problem with its severity, its category and the object it concerns; a double-click selects and frames that object on the map.

   

5. Calculate

   Built

   Calculate (F5) runs the engine in a separate worker process, so the application stays usable. The Calculation tab shows the plan and the progress of receivers, work units and receiver grids, and a run can be cancelled. After an edit, incremental recalculation redoes only what the edit affects. The study settings choose the method edition, including the Dutch adaptations of CNOSSOS-EU and method I of Bijlage IVh, and the highest number of reflections in a path; the run records both.

   

6. Review the results

   Built

   The results show on the map with a legend: receivers coloured by their level and contours of receiver grids, in the colour scales of DIN 45682: the general scale (Table B.1), in 5 dB classes from up to 35 dB to over 80 dB, or the scale for strategic noise maps under the Environmental Noise Directive (Table B.2). The Results panel lists the runs, and every run is kept next to the study with its manifest, so it can be opened again later. The Receiver results table lists every receiver at every height, marks receivers that changed since the run, and exports to CSV; with a receiver selected, the Properties panel shows its levels and the contribution of each source, highest first. The map and the table show the A-weighted level or one octave band of it, from 31,5 Hz for Bijlage IVh to 8 kHz, and a run of Bijlage IVh also has the maximum levels LAmax_day, LAmax_evening and LAmax_night.

   

   

7. Deliver a strategic noise map

   Built

   The grid preset Strategic noise map (END) sets a grid to 4 m and to the END classes of Lden and Lnight. File ▸ Export ▸ END noise map delivery… fills in the delivery of an agglomeration or of major roads: find the municipality by name or CBS code, and Studio lists its agglomeration and the noise sources the RIVM manual asks of it; choose per source the contours of a grid of the study or a polygon file made elsewhere, and type the numbers of people per class. The export runs in the background and writes the delivery only when the engine’s check finds no error; its findings appear in the Problems panel with the clause of the manual. File ▸ Check END delivery… checks a delivery made elsewhere. Both are checked against the documented Cvgg checks of the 2026 manuals.

Studio has a light and a dark theme, and keeps its settings, workspaces and logs per user.

Built for speed

Exact and fast are not a trade-off in Attenix. Speed comes from how the calculation is organised, not from shortcuts in the method: the results are the same to the bit on one thread or on all of them.

• Every core: receivers are grouped into independent work units that run in parallel, and the per-path formulas run in SIMD instructions. Emission is calculated once per work unit, and the scene’s spatial index and terrain once per calculation.
• Only what changed: after an edit, incremental recalculation redoes only the receivers whose paths the edit can reach; a change of traffic only sums again. In a dense district, 95 receivers were updated after a traffic change in 0,87 s instead of 19 s for a full calculation.
• Kept fast: benchmarks of every hot path and of end-to-end reference scenes run against a stored baseline; a change that makes a reference scene more than 10 % slower is reported as a regression.
• Large files in Studio: a height model of 1 GB (10 km × 10 km in cells of 0,5 m) has its display built once in about 36 s, in the background while Studio stays usable, and opens from the display cache in under 0,2 s after that (measured on 2026-10-08 on the same processor). In a study with 105 150 roads, selecting all rows of their table (Ctrl+A) highlights them on the map in about 0,05 s instead of 2,7 s before (measured the same day on the same machine).

Times depend strongly on the scene: most of the time goes into finding the paths, and reflections in a dense scene make up most of that. These are measurements on one machine, not guarantees.

Not in the first release

So that nobody plans around a feature that does not exist yet:

• Other sources: emission is implemented for road traffic, for industry (Bijlage IVh and CNOSSOS-EU) and, by CNOSSOS-EU, for railway traffic. Railway noise by the Dutch method, Bijlage IVf, is not covered yet, and aircraft noise is not covered. The reflections between a train and a nearby barrier (Delegated Directive (EU) 2021/1226, §2.5.6) are not calculated yet.
• Attenix Studio: railway tracks cannot be drawn or calculated in Studio yet; the engine calculates them. A run in Studio uses one method edition, so a study with roads and industrial sources is calculated in two runs.
• RMG 2012: of the method before the Omgevingswet, only Standaardrekenmethode 2 for road traffic is implemented.
• Exposure: the END delivery takes the numbers of people and dwellings per class from the user; Attenix does not compute exposure yet.
• Bijlage XXXIII for 2027: cnossos-eu.road.nl@2027 follows a proposal, not a text in force.
• Release terms: the release date, licensing and prices are not yet announced.