UDSSimHSFZ Demo
***************
This demo configuration shows the usage of High Speed Fahrzeug Zugang (HSFZ) protocol
in CANoe.

You can change to the ISO13400 Diagnostics over IP (DoIP) protocol by simply changing
the selected protocol version to "DoIP V1 (Draft version 2010)" or "DoIP V2 (ISO 13400-
2:2012)" in the Diagnostics/ISO TP Configuration dialog, page Additional Diagnostic
Settings\DoIP/HSFZ Main Settings.

The basic functionality (diagnostic ECU simulation, SecurityAccess) as well as the
simulation code used for the node "ECU" is identical to the UDSSim Demo on CAN (ISO TP).

In addition to the UDSSim demo, this demo shows
- two CAPL test modules which implement a flash download of data in 64k / 4k data
  blocks respectively to two simulated diagnostic targets via HSFZ and diagnostic
  services,
- a simulated HSFZ/CAN gateway for routing the diagnostic communication between the
  HSFZ testers and the ECUs on the standard network (CAN in this example) - the
  HSFZ/CAN gateway itself also implements a diagnostic server and can be diagnosed
  via HSFZ e.g. using the Diagnostics Console,
- the effects of switching the diagnostic access for a complete network between HSFZ
  or a standard network. By marking/unmarking the 'Enable diagnostics via common DoIP/HSFZ
  gateway for this network' checkbox in the Diagnostics / ISO TP configuration dialog,
  either HSFZ is used by testers /diagnostic consoles or the respective CAN ISO TP 
  channel.

The UDSSimHSFZ Demo contains an ECU simulation whose state is displayed in the "ECU"
panel:

- "Active Session":

  A car symbol with closed hood for default session (ECU always locked), open hood
  for extended session (unlocking of ECU is possible), and a computer symbol for the
  programming session.

  Note that the ECU falls back into the locked default session if no requests are
  received for P3 time. If you manually deactive TesterPresent sending, you have to
  activate it again manually to keep the ECU in a non-default session.

- "ECU Status":
  The ECU can be locked, i.e. certain services may not be executed and the ECU will
  deny security access. If a request is received where positive responses are
  suppressed  (new UDS feature), the LED will light a short time.
  If the ECU sends a negative response, that LED will light up.

- "Serial Number", "Device Control", "Variant Coding Data":
  These values can be changed and queried via the diagnostics console or the variant
  coding control (cf. below).

- "Fault Memory":
  The ECU holds a memory for DTC snapshot values that can be accessed from the
  diagnostics console or the fault memory window. You can add additional snapshots
  by selecting a DTC with the slide bar and pressing the button "Add Snapshot Record".
  This is only possible if some bits are selected.

- "Expected Security Key":
  In order to make it possible for a human user to unlock the ECU from the diagnostics
  console manually, the panel shows the key value the ECU expects at the moment.
  Do not expect to find such a display on a real ECU.

  The "SeednKey.dll" CAPL-DLL offers a simple and flexible solution for generating
  diagnostic securityAcces keys by encapsulating the actually used / OEM specific
  security access DLL in a generic API.

  In our example, the simulated "ECU" sends the SecuritySeed to the SeednKey.dll.
  From there, the SeednKey.dll transmit this Seed to the demo SecurityAcces-Key
  "SeednKey.dll". The return value is the calcuated SecuritySeed.


Configured panels
===========

- Diagnostics Console:
  This module displays all diagnostics services, which are defined in the diagnostics
  description (*.cdd file). Services can be selected, parameterized and sent via the
  Diagnostics Console.
  The controller's responses are also displayed in this console.

- "UDSVariantCodingPanel":
  This is an example for a VisualBasic 6.0 ActiveX control, you will find the source code
  in the directory "VariantCodingPanel".
  The changing of the ECU variant requires a sequence of requests which is coded into
  this control to demonstrate how such complex algorithms may be realized.

Variant Coding Algorithm
===============

Please have a look at the state transistion definitions for services defined in the CDD!
You can restrict execution to certain sessions or lock states and define session
transistions. This is implemented in this example ECU:

- Accessing the variant coding data is only possible in the unlocked programming
  session.
- The programming session can only be actived if the ECU is unlocked already.
- Unlocking the ECU is not possible in the default session.
- Changing a session will always lock the ECU.
- After the variant has been changed, a reset has to be performed to allow the  ECU
  to reconfigure itself.
- While the ECU is resetting, it does not react on requests.

Therefore the algorithm to set the variant coding is as follows:
1. Activate extended session
2. Unlock the ECU (requesting seed and sending key)
3. Activate programming session
4. Unlock the ECU (requesting seed and sending key)
5. Set the variant coding data
6. Reset the ECU
7. Wait for some time to allow the ECU to reconfigure itself
8. Activate default session

This algorithm is implemented in the variant coding panel.

*********************************************************************
A detailed description can be found in the online help (see example configurations
in the table of contents).
*********************************************************************

-------------------------------------------------------------------------------------------------------
Copyright (c) by Vector Informatik GmbH Dep. Tools Automotive 2009
-------------------------------------------------------------------------------------------------------