Skip to content
  • There are no suggestions because the search field is empty.

DADAS reporting overview

An introduction to DADAS reporting - web-based viewer, report types, exports and practical advice.

Purpose

This article explains the reporting features of the DADAS platform in simple terms. It covers web-based reporting, the common report types, export formats, scheduling and the practical choices that make reports useful for operations and support.

What DADAS reports are

DADAS reports collect time-stamped measurements, system status and diagnostics into a single document. Reports can be a snapshot (now), a short period (minutes or hours) or a longer window (for example 24 hours). They are used for shift summaries, troubleshooting, incident analysis and for providing evidence during acceptance or audits.

Web-based reporting and the report viewer

Modern DADAS installations include a web-based report viewer where you can preview, edit, print and export reports. The viewer provides basic toolbar actions such as print, navigation and on-screen editing, and lets you check pages before you save or send the report. The viewer also supports multiple export formats and parameters so you can choose the best format for your audience.

Common report types

  • Generic site reports — non-regulatory reports that combine weather, motion, sea state and system status as available; used for operations and support.

  • Template reports — predefined layouts for specific needs such as helideck reporting; templates ensure consistent fields and presentation across sites.

  • Scheduled or automated reports — recurring exports sent by email, FTP/SFTP or other endpoints for daily logs and audit trails.

Export formats and practical guidance

The report viewer supports a range of export formats. Choose the format that best fits the recipient:

  • PDF — best for operator summaries and human reading; use WYSIWYG and embedded fonts for fidelity.

  • CSV — best for engineers and historians; check CSV options such as separator, codepage and the “data only” setting before export. CSV is ideal when you need raw tables for analysis.

  • Excel, HTML or RTF — useful when recipients need editable tables or spreadsheet features.

  • FPX / native format — preserves report pages for later editing in the report tool.

When exporting, always check key export options such as page breaks, embedded fonts, WYSIWYG mode and codepage because they affect file size, readability and downstream compatibility.

Scheduling and automated exports

You can schedule reports to run automatically and deliver the output by email, FTP or SFTP. When using scheduled reports, agree a clear naming convention and retention policy so files are easy to find. Automated reports are useful for routine audit evidence and daily operations logs.

Time handling and averaging windows

Reports often show both instantaneous samples and reduced values (for example 10-minute means). Always check the report’s time standard (UTC is recommended) and the averaging windows used. Differences between UI values and report values usually come from aggregation or unit differences.

What to include for useful support reports

For support and incident analysis include:

  • Start and end timestamps in UTC.

  • A tag list with short descriptions and units.

  • Averaging windows or reduction methods for each field.

  • Sensor status, quality flags and last-update timestamps.

  • Active alarms for the period.

  • A short operator note describing what was observed and any operator actions.

Troubleshooting common report issues

  • Frozen or stale values: check sensor last-update timestamps and communications indicators.

  • Different values in UI and report: verify averaging windows and units.

  • Missing sections: usually means the site lacks the corresponding module or the template does not include that section.

  • Export failures (FTP/SFTP): confirm credentials, firewall rules and that the export host has sufficient resources for large exports.

What support needs from you

When you open a ticket, include:

  • A generic DADAS report covering the incident window (or the scheduled report name and timestamp).

  • The exact UTC range and a short operator note.

  • Any screenshots, alarm IDs and the “last update” times for affected sensors. Good reports help support reconstruct the incident quickly and reduce back-and-forth.

Key recommendations

  • Use UTC timestamps and state averaging windows clearly.

  • Use PDF for summaries and CSV for engineering analysis.

  • Always include sensor quality flags and last-update times.

  • Attach a brief operator note when contacting support.