Files
DP44/enriched-qwen3-coder-next/Common/DTS.Common.Serialization/Control/DAS.md
2026-04-17 14:55:32 -04:00

6.4 KiB
Raw Blame History

source_files, generated_at, model, schema_version, sha256
source_files generated_at model schema_version sha256
Common/DTS.Common.Serialization/Control/DAS/IFilterable.cs
Common/DTS.Common.Serialization/Control/DAS/IFilter.cs
2026-04-16T03:41:25.272025+00:00 Qwen/Qwen3-Coder-Next-FP8 1 d1bb42983adadb6c

DAS

Documentation: IFilterable and IFilter Interfaces


1. Purpose

This module defines core interfaces (IFilterable and IFilter) for managing and applying signal filters to channel data within the DTS Slice Control DAS (Data Acquisition System) framework. It enables consumers to query available filters, set a current filter, optionally cache filter results for performance, and retrieve filtered data in specified display units. The interfaces serve as abstractions for channel filtering logic—likely implemented by concrete classes representing physical or logical channel groups in the control system.


2. Public Interface

IFilterable Interface

Namespace: DTS.Slice.Control.DAS.Channel

Member Signature Description
UseFilterCaching bool UseFilterCaching { get; set; } Enables or disables caching of previously computed filtered results.
AvailableFilters List<IFilter> AvailableFilters { get; } Returns a list of filters that can be applied to this object.
CurrentFilter IFilter CurrentFilter { get; set; } Gets or sets the filter currently applied to data requests.
GetDataFilteredBy double[] GetDataFilteredBy(IFilter filter, Event.Module.Channel.DataDisplayUnits displayUnits) Returns filtered data for the specified filter and displayUnits.

IFilter Interface

Namespace: DTS.Slice.Control.DAS.Channel

Member Signature Description
Name string Name { get; } Returns a human-readable name/description of the filter.
IsCfc bool IsCfc { get; } Indicates whether the filter represents a cardinal CFC (Cycle Count Filter) value.
Type ChannelFilter Type { get; } Returns the filters type (e.g., low-pass, high-pass), represented by the ChannelFilter enum (not shown in source).
CutoffFrequencyHz double CutoffFrequencyHz { get; } Returns the cutoff frequency (in Hz) used by the filter.
Apply (1) double[] Apply(Event.Module.Channel input, Event.Module.Channel.DataDisplayUnits displayUnits, bool bUseLegacyTDCSofwareFilterAdjustment) Applies the filter to channel data, converting to displayUnits. The bUseLegacyTDCSofwareFilterAdjustment flag adjusts output one sample to the right for backward compatibility with legacy TDC software.
Apply (2) double[] Apply(double[] data, double sampleRate, bool bUseLegacyTDCSoftwareFilterAdjustment) Applies the filter to raw numeric data (assumed to be in base units), given the sampleRate. Same legacy adjustment flag applies.
ToBaseString string ToBaseString() Returns the base name of the filter (e.g., "LowPass"), without any decoration (e.g., no suffix like " (10 Hz)").

Note

: The Apply methods are overloaded: one accepts an Event.Module.Channel object (likely containing metadata and raw data), and the other accepts raw double[] data plus sampleRate.


3. Invariants

  • AvailableFilters must be non-null and immutable in the sense that its contents should not change during the lifetime of the IFilterable instance (though the list itself may be recreated on each access).
  • CurrentFilter must be either null or one of the items in AvailableFilters.
  • GetDataFilteredBy must return data consistent with the specified filter and displayUnits, and must not mutate the underlying channel data.
  • IsCfc and Type must be consistent: if IsCfc is true, then Type likely corresponds to a CFC-specific ChannelFilter value (exact mapping not specified in source).
  • The bUseLegacyTDCSofwareFilterAdjustment parameter in Apply controls sample alignment: when true, output is shifted one sample to the right (i.e., delayed by one sample period) to preserve legacy behavior.

4. Dependencies

Dependencies of this module:

  • System.Collections.Generic (List<T>)
  • DTS.Common.Utilities (namespace referenced, but no types used directly in interface definitions)
  • Event.Module.Channel (used in Apply signatures; type not shown, but assumed to contain raw channel data and metadata)
  • Event.Module.Channel.DataDisplayUnits (enum or type defining unit conversion options; not shown)

Dependencies on this module:

  • Any class implementing IFilterable (e.g., channel or group implementations) must provide filtering capabilities.
  • Any class implementing IFilter must define concrete filtering logic (e.g., LowPassFilter, HighPassFilter, CfcFilter).
  • Likely used by higher-level components in DTS.Slice.Control.DAS or DTS.Slice.Control.CAS namespaces (inferred from commented-out base interface in IFilterable).

5. Gotchas

  • Typo in parameter name: In GetDataFilteredBy, the parameter filter is documented as DTS.Slice.Control.CAS.Channel.IFilter, but the actual interface is DTS.Slice.Control.DAS.Channel.IFilter. This may indicate outdated documentation or namespace refactoring.
  • Typo in flag name: bUseLegacyTDCSofwareFilterAdjustment is misspelled as Sofware (missing 't') in one Apply signature (Apply overload 1), but correctly spelled as TDCSoftware in the second overload. This inconsistency may cause confusion or errors in code generation or reflection-based usage.
  • No explicit thread-safety guarantees: Neither interface documents thread-safety; concurrent access to CurrentFilter, UseFilterCaching, or Apply may require external synchronization.
  • Caching behavior unspecified: While UseFilterCaching toggles caching, the caching strategy (e.g., cache key, eviction policy, scope) is not defined here—implementation-specific.
  • ToBaseString() vs ToString(): The comment implies ToString() is overridden elsewhere (likely in concrete implementations) to include metadata (e.g., "LowPass (10 Hz)"), while ToBaseString() returns the base name only. Consumers must be aware of this distinction when displaying filter names.

None identified from source alone.
(Note: The above gotchas are inferred from inconsistencies in naming and documentation; no behavioral quirks beyond those are evident from the interfaces themselves.)